date:20180710


Below is an example of Jol, and the equivalent JCL.

Clem

Simplified Jol Scripting Language for Z/OS, TSO, Linux and Windows

Payroll: Job class C 1000 k;
Exec Validate Input.Trans, Trans.Action(+1); /* Validate Transations */
if Validate=0
then do;
    Sort transaction(+1) to Sorted.Trans.Actions(+1)
        Fields(10,10,CH,A);
    Exec Update Payroll.Master(0), Sorted.Trans.Action(+1),
        Payroll.Master(+1);
    If Update = 0
    then do;
        Catalog Payroll.Master(+1), Sorted.Trans.Action(+1);
        Submit Job2;
    end;
end;
else Stop 'Error in PAYROLL Job';




Equivalent Existing Job Control Language


//PAYROLL   JOB      CLASS=C,REGION=1000K
//VALIDATE   EXEC     PGM=VALIDATE
//SYSPRINT   DD       SYSOUT=*
//INTRANS    DD       DSN=INPUT.TRANS,DISP=SHR
//OUTTRANS   DD       DSN=TRANS.ACTIONS(+1),DISP=(NEW,PASS),
//        DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
//        SPACE=(CYL,(10,10),RLSE),
//        UNIT=SYSDA,VOL=SER=WORK01
//SORT   EXEC     PGM=SORT,COND=(VALIDATE,NE,0)
//SYSOUT DD       SYSOUT=*
//SORTWK01   DD       UNIT=SYSDA,SPACE=(CYL,20)
//SORTWK02   DD       UNIT=SYSDA,SPACE=(CYL,20)
//SORTWK03   DD       UNIT=SYSDA,SPACE=(CYL,20)
//SORTIN DD       DSN=TRANS.ACTIONS(+1),DISP=(SHR,PASS)
//SORTOUT    DD       DSN=SORTED.TRANS.ACTIONS(+1),
//        DISP=(NEW,PASS),
//        DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
//        SPACE=(CYL,(10,10),RLSE),
//        UNIT=SYSDA,VOL=SER=WORK01
//SYSIN  DD   *
    SORT FIELDS=(10,10,CH,A)
//UPDATE EXEC     PGM=UPDATE,COND=(VALIDATE,NE,0)
//SYSPRINT   DD       SYSOUT=*
//MASTIN DD       DSN=PAYROLL.MASTER(0),DISP=SHR
//TRANS  DD       DSN=TRANS.ACTION(+1),DISP=(SHR,PASS)
//MASTOUT    DD       DSN=PAYROLL.MASTER(+1),DISP=(NEW,PASS),
//        DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
//        SPACE=(CYL,(10,10),RLSE),
//        UNIT=SYSDA,VOL=SER=WORK01
//CATLG  EXEC     PGM=IEFBR14,COND=(UPDATE,NE,0)
//DUMMY1 DD       DSN=PAYROLL.MASTER(+1),DISP=(SHR,CATLG)
//DUMMY2 DD       DSN=SORTED.TRANS.ACTIONS(+1),
//            DISP=(SHR,CATLG)
//SUBMIT EXEC     PGM=IEBGENER,COND=(UPDATE,NE,0)
//SYSPRINT   DD       SYSOUT=*
//SYSUT1 DD       DSN=SUBMIT.LIBRARY(JOB2),DISP=SHR
//SYSUT2 DD       SYSOUT=(*,INTRDR)
//SYSIN  DD       DUMMY
//ERRMSG EXEC     PGM=SHOWERR,COND=(VALIDATE,EQ,0),
//   PARM='Error in PAYROLL Job'



Andrew Rowley wrote:

On 9/07/2018 10:46 PM, Hobart Spitz wrote:


Basically, JCL is so far from real a programming language, that I can't
describe it.

That's because JCL isn't a programming language. There are plenty of 
other languages that also suck as programming languages e.g. HTML, 
XML, JSON, but that's not what they are supposed to be.


JCL is really a kind of definition language. In programming language 
terms it is more like a set of classes in OOP than a language in 
itself: you have a job, which has steps, steps have DDs etc. The 
syntax is old fashioned, but the concepts are very much OOP. It would 
be relatively simple to create a set of classes in your OOP language 
of choice to hide the syntax - just create a Job object, add Step 
objects, add DataDefinition objects etc. and have a Submit method emit 
JCL.


If I want to write a program, I will choose a programming language. If 
I want to define a unit of work to the system, JCL does a pretty good 
job. I definitely prefer JCL to long command lines with multiple 
switches and options defining input and output files, which is the 
non-z/OS equivalent.


Andrew Rowley
Black Hill Software

--
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: IBM i as JCL replacement (was: Rexx as JCL replacement)


Jol has a comprehensive menu system too.

Or it can be used with a PL/I type English like script.

For example,

    Testjob: job;
    Print Sys1.Maclib(call);

Clem

Jantje. wrote:

On Thu, 5 Jul 2018 15:08:01 -0500, Dana Mitchell  wrote:


Most everything is menu driven,

Indeed it is, but hitting PF14 on that menu will show you the equivalent CL command 
with all the options you just filled in in the right place and with the correct 
syntax. Just cut that into your CL source... or onto your command line 
for that matter.


Cheers,

Jantje.

--
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: REXX as JCL replacement


Paul Gilmartin wrote:

On Thu, 5 Jul 2018 14:23:35 -0400, Hobart Spitz wrote:


I think a more encompassing approach would be for JOL to be a function,
command or environment which could be invoked from REXX.


JOL could be invoked from REXX. Or JCL.
When the JOL *compiler* is invoked from TSO though, the Panels and other 
functions can be used to interact with the user, and suggested by the 
main screen shown at www.Oscar-Jol.com


The job can then be submitted to batch to run, or executed under TSO.


I wonder how JOL addresses theneed for "parallel ENQs".  S99WTDSN requires
APF authorization.  Does JOL submit "optimized" JCL, or is it authorized so it
can do all the initiator does to run a mix of authorized and unauthorized steps.

Jol executes user programs in two main ways.

1. Jol can produce JCL which is run under the control of a "monitor" 
program that catalogs data sets and runs programs underneath it.


2. It can use Dynamic Allocation and effectively replace the Initiator.
    a) When the job is to be executed under TSO, no JCL is produced at all.
    b) When submitted to batch, it produces some JCL to invoke the Jol 
monitor, which does all the data set allocation and executes the problem 
program.




... text deleted
UNIX has never had a separate batch scripting language.

There is a alpha test version of Jol that does run under Linux and 
execute user programs, much like Z/OS batch.


That version of Jol is written in "C" and can produce Z/OS JCL, or run 
Windows or Linux programs. It could be ported to Z/OS.


It also can produce VSE code, although it is in testing mode only.

Clem

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

Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?

2018-07-10 Thread Edward Finnell

Don't forget to increment the LABEL=


In a message dated 7/10/2018 6:38:33 PM Central Standard Time, 
clementcla...@ozemail.com.au writes:

 
VOL=REF=*.Ddname can be used here.

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

Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?


VOL=REF=*.Ddname can be used here.

It seems that once you refer to a data set on the Passed Data Set Queue, 
then it has been marked as received, and hence cannot be referenced 
again in the same job step.


However, using a previous ddname overcomes that, and also picks up the 
correct volume if a tape fills, and another is being written to.


Clem

Dyck, Lionel B. (RavenTek) wrote:

The use we need to to xfer a tape with multiple files on it (label=1,2,3,) 
and thus need the vol=ref.

The working syntax after a suggestion from ibm is VOL=(,RETAIN,REF=dsn)

And since we are using GDG's it must be VOL=(,RETAIN,REF='dsn')

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer – RavenTek Solution Partners

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: Tuesday, July 03, 2018 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?

Wow, this doc is not formatted the way it used to be.

When one does a copy, one can send the data or one can pull the
data. Let us assume that the system that starts the process is
the one in control (Process control *AND* PNODE), and that one is
going to copy *from* the PNODE to the SNODE (again, it can be
done the other way).

Now, where the data set is going *TO* one can use REF=dsn, and
this will force that data set being copied to the same VOLUME as
the DSN specified by the REF=.

Why would one want to do this?

One may want or need to do this because one knows the name of a
DSN on the client's system and by using that reference, one can
put another file over there where the client has asked for it to be.

HTHs

Steve Thompson






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

Re: REXX as JCL replacement

Don't know about that! I always think that IBM has some of the best 
people and concepts.  Pity IBM didn't push PL/I instead od allowing C to 
rule the world.


However, there's an interesting IBM lab in Perth that has some excellent 
people. Not many people know about it.


I worked there for a few years. Loved it.

Clem


zMan wrote:

What would it take for IBM to allocate just a couple of people to make it

available as a supported product?


Having someone left in POK who knows how to code. Not sure there's anyone
left...

--
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: Sysplex between two hardware

2018-07-10 Thread Jesse 1 Robinson

It's easy to diss a solution as 'budget' when it saves someone *else* money. 
The notion that a third CEC for standalone CF is substantially better than ICF 
is illusory. If you truly believe that one extra CEC is necessary, then you 
really need two extra CECs for CF because there are times when you have to take 
one of them down. Maybe for repair, maybe for upgrade. So you still need a 
backup. 

OTOH, 'logical standalone'--interesting term--with an ICF in each z/OS CEC is a 
sufficient solution. We've run this way for years and survived two separate 
hard-down CEC failures with zero recovery agony. My recommendation is to run 
two CECs, one substantial box to run application hosts, and a minimal 'penalty 
box' just for ICFs plus a few high-cost products that bill significantly less 
on a small CEC. With proper structure duplexing, you have extraordinary 
redundancy at a reasonable cost. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, July 10, 2018 3:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Sysplex between two hardware

W dniu 2018-07-10 o 06:56, Timothy Sipples pisze:
> I should also respond to this part:
>
> Radoslaw Skorupka wrote:
>> ...for availability reasons one should avoid having CF and z/OS LPAR 
>> on the same hardware, which means
> That's not phrased as IBM would phase it, and it's not correct as written.
>
> Even when there's some merit in physically separating the CF, the 
> physical separation need only be between that CF and the particular 
> z/OS Parallel Sysplex it serves. Having other z/OS LPARs, even LPARs 
> that are participating in other Parallel Sysplexes, on the same 
> machine as the CF is consistent with IBM's recommendations here.
>
> David Raften has published a whitepaper (updated in May, 2018) that 
> explains the various CF configuration options. The direct link to the 
> current edition is here:
>
> https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971u
> sen-.pdf
[...]

I quickly browsed the document and found confirmation what I learned several 
years ago.
That means:
Yes, you need either standalone CF (*see note) or CF structure duplexing! This 
is required for *some* structures, but ...it is. David Rften call it structures 
which /require failure independence/.

Note: Standalone CF should be understood here as LOGICAL stand alone CF.
IBM-MIAN do not allo pictures, so I'll try to describe it:
SYSPLEX PROD:
z/OS 1 in CPC A, z/OS 2 in CPC B, and CF2 in CPC B or A. And CF1 in CPC C.
Three CPCs.
However CPC C may be used for other purpose, i.e. for test LPARs. 
Anything but z/OS image belonging to the sysplex PROD.

There is also two-CPC configuration
z/OS 1 + CF1 in CPC A, z/OS 2 + CF2 in CPC B and *some structures are duplexed*.
What I heard unofficially from IBM-ers is such configuration is "budget" 
read: when you cannot afford good one.
And the link between CFs should be really local (short).

Note2: it is also possible to build a configuration without dedicated 
(logical stand alone) CF and without duplexing. Your choice.
However it is NOT resistant to all possible (single) failures. Yes, it 
is still better than parallel sysplex with single CF, but still 
vulnerable to some failures.

-- 
Radoslaw Skorupka
Lodz, Poland

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

Re: z/OS JCl vs. VSE JCL: VSAM files

2018-07-10 Thread Hobart Spitz

John wrote:
>it is not the default but is the only correct way to access a vsam file.
>disp=shr,dsn=.vsam (possible bufno,bufni,...etc)
Does any one know it that also applies to PDSEs?  AFAIK, they are VSAM
datasets.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Tue, Jul 10, 2018 at 6:33 PM, John Clifford  wrote:

> it is not the default but is the only correct way to access a vsam file.
> disp=shr,dsn=.vsam (possible bufno,bufni,...etc)
>
> Never disp=new or delete.   Disp=old can be used if you need to make sure
> you are the only one accessing the file but if it is open in CICS it will
> hang.
>
> On Tue, Jul 10, 2018 at 6:07 PM, Tony Thigpen  wrote:
>
> > So, DISP=SHR is not the default, as I thought was implied by John's
> > statement that "Z/os VSAM is always accessed as DISP=SHR."
> >
> > Tony Thigpen
> >
> > Gibney, Dave wrote on 07/10/2018 05:49 PM:
> >
> >> If DISP=SHR (that is if not DISP is provided), then the JCL Default of
> >> (NEW,PASS) would happen and the job would fail
> >>
> >> -Original Message-
> >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> >>> On Behalf Of Tony Thigpen
> >>> Sent: Tuesday, July 10, 2018 2:43 PM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: z/OS JCl vs. VSE JCL: VSAM files
> >>>
> >>> Then, why does every VSAM DD for every z/OS site I have worked with,
> >>> always include DISP=SHR?
> >>> (I guess, because it's a habit from non-VSAM files and nobody told them
> >>> they
> >>> did not have to do it.)
> >>>
> >>> Tony Thigpen
> >>>
> >>> John Clifford wrote on 07/10/2018 04:16 PM:
> >>>
>  Z/os VSAM is always accessed as  DISP=SHR.
> 
> >>>
> >>> --
> >>> For IBM-MAIN subscribe / signoff / archive access instructions, send
> >>> email to
> >>> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>>
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >>
> >>
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: z/OS JCl vs. VSE JCL: VSAM files

2018-07-10 Thread Gibney, Dave

Actually, I think that inside VSAM, what is specified via SHAREOPTIONS would 
override any JCL. But, you need to get past the JCL during allocation before 
VSAM can take over.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tony Thigpen
> Sent: Tuesday, July 10, 2018 3:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS JCl vs. VSE JCL: VSAM files
> 
> So, DISP=SHR is not the default, as I thought was implied by John's statement
> that "Z/os VSAM is always accessed as DISP=SHR."
> 
> Tony Thigpen
> 
> Gibney, Dave wrote on 07/10/2018 05:49 PM:
> > If DISP=SHR (that is if not DISP is provided), then the JCL Default of
> > (NEW,PASS) would happen and the job would fail
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> >> On Behalf Of Tony Thigpen
> >> Sent: Tuesday, July 10, 2018 2:43 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: z/OS JCl vs. VSE JCL: VSAM files
> >>
> >> Then, why does every VSAM DD for every z/OS site I have worked with,
> >> always include DISP=SHR?
> >> (I guess, because it's a habit from non-VSAM files and nobody told
> >> them they did not have to do it.)
> >>
> >> Tony Thigpen
> >>
> >> John Clifford wrote on 07/10/2018 04:16 PM:
> >>> Z/os VSAM is always accessed as  DISP=SHR.
> >>
> >> -
> >> - For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO
> >> IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: z/OS JCl vs. VSE JCL: VSAM files

2018-07-10 Thread Gibney, Dave

My memory was wrong on normal termination. I rarely use DISP defaults. I would 
expect you are correct for the MOD instance

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Tuesday, July 10, 2018 3:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS JCl vs. VSE JCL: VSAM files
> 
> On Tue, 10 Jul 2018 21:49:47 +, Gibney, Dave wrote:
> 
> >If DISP=SHR (that is if not DISP is provided), then the JCL Default of
> >(NEW,PASS) would happen and the job would fail
> >
> From the JCL Ref.
> Defaults
> v If you omit the status subparameter, the default is NEW.
> v If you omit the normal termination disposition subparameter, the default
> is
>   DELETE for a NEW data set or KEEP for an existing data set.
> 
> Hmmm.  Does this mean that fmr status MOD the data set will be deleted if
> allocation created it but kept if it existed beforehand?
> 
> -- 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: z/OS JCl vs. VSE JCL: VSAM files

So, DISP=SHR is not the default, as I thought was implied by John's 
statement that "Z/os VSAM is always accessed as DISP=SHR."


Tony Thigpen

Gibney, Dave wrote on 07/10/2018 05:49 PM:

If DISP=SHR (that is if not DISP is provided), then the JCL Default of 
(NEW,PASS) would happen and the job would fail


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Tony Thigpen
Sent: Tuesday, July 10, 2018 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS JCl vs. VSE JCL: VSAM files

Then, why does every VSAM DD for every z/OS site I have worked with,
always include DISP=SHR?
(I guess, because it's a habit from non-VSAM files and nobody told them they
did not have to do it.)

Tony Thigpen

John Clifford wrote on 07/10/2018 04:16 PM:

Z/os VSAM is always accessed as  DISP=SHR.


--
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: z/OS JCl vs. VSE JCL: VSAM files

2018-07-10 Thread Paul Gilmartin

On Tue, 10 Jul 2018 21:49:47 +, Gibney, Dave wrote:

>If DISP=SHR (that is if not DISP is provided), then the JCL Default of 
>(NEW,PASS) would happen and the job would fail
> 
From the JCL Ref.
Defaults
v If you omit the status subparameter, the default is NEW.
v If you omit the normal termination disposition subparameter, the default 
is
  DELETE for a NEW data set or KEEP for an existing data set.

Hmmm.  Does this mean that fmr status MOD the data set will be deleted if 
allocation
created it but kept if it existed beforehand?

-- gil

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

Re: z/OS JCl vs. VSE JCL: VSAM files

On z/VSE, there is not a LIKE option in the DLBL card. We must use 
IDCAMS DEFINE with MODEL(other file name) to get the same results as LIKE.


Tony Thigpen

Farley, Peter x23353 wrote on 07/10/2018 04:05 PM:


Creating a VSAM cluster may often require IDCAMS DEFINE, but the JCL LIKE 
parameter is your friend if for instance you are making a copy of a production 
file for a unit test run.  Just use the UNIT and SPACE parameters to allocate 
space and all else will be copied from the LIKE cluster.

Now if any of the LIKE cluster parameters are incompatible with your immediate 
need (REUSE vs NOREUSE perhaps, or LOG parameters for RLS) then you do need 
DEFINE, but the JCL DELETE works without an issue that I am aware of.

Peter



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

Re: z/OS JCl vs. VSE JCL: VSAM files


For normal z/VSE VSAM:
1) you can use DISP=NEW, which resets the High RBA at open if the file 
is defined with REUSE.
2) you can use DISP=DELETE, which resets the High RBA at close if the 
file is defined as REUSE. (note: Space is not released.)
3) with very limited exceptions, you always use IDCAMS to define or 
delete the VSAM file.

4) the default is DISP=(OLD,KEEP,KEEP) is the default.

The limited exception mentioned is when using "VSAM managed SAM files". 
You don't have these on z/OS. (AFAIK) I will discuss them after I 
discuss regular non-VSAM files.


So, for most situations, DISP= is not specified on the z/VSE DLBL card.

Tony Thigpen

Wayne Bickerdike wrote on 07/10/2018 03:52 PM:

*How can it infer the difference between KEEP and DELETE?  (Or is thatthe
"mostly" part?)-- gil*




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

Re: z/OS JCl vs. VSE JCL: VSAM files

2018-07-10 Thread Gibney, Dave

If DISP=SHR (that is if not DISP is provided), then the JCL Default of 
(NEW,PASS) would happen and the job would fail

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tony Thigpen
> Sent: Tuesday, July 10, 2018 2:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS JCl vs. VSE JCL: VSAM files
> 
> Then, why does every VSAM DD for every z/OS site I have worked with,
> always include DISP=SHR?
> (I guess, because it's a habit from non-VSAM files and nobody told them they
> did not have to do it.)
> 
> Tony Thigpen
> 
> John Clifford wrote on 07/10/2018 04:16 PM:
> > Z/os VSAM is always accessed as  DISP=SHR.
> 
> --
> 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 JCl vs. VSE JCL: VSAM files

Then, why does every VSAM DD for every z/OS site I have worked with, 
always include DISP=SHR?
(I guess, because it's a habit from non-VSAM files and nobody told them 
they did not have to do it.)


Tony Thigpen

John Clifford wrote on 07/10/2018 04:16 PM:

Z/os VSAM is always accessed as  DISP=SHR.


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

Re: z/OS JCl vs. VSE JCL: VSAM files

2018-07-10 Thread John Clifford

Z/os VSAM is always accessed as  DISP=SHR.

On Tue, Jul 10, 2018 at 3:52 PM, Wayne Bickerdike  wrote:

> *How can it infer the difference between KEEP and DELETE?  (Or is thatthe
> "mostly" part?)-- gil*
>
>
> *On Wed, Jul 11, 2018 at 4:48 AM, Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu
> <000433f07816-dmarc-requ...@listserv.ua.edu>> wrote:*
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > *On Tue, 10 Jul 2018 14:23:34 -0400, Tony Thigpen wrote: > >Take a simple
> > "I want to use a VSAM file". Here is what is normally used: >z/OS:
> > >//POLYUPD  DD DSN=PROD.HKY.VSAM.HPP002P.F03,DISP=SHR >z/VSE: >// DLBL
> > TEITEST,'TEI.TEST.VSAM',,VSAM,CAT=VSESPUC > >z/OS (mostly) requires a
> > DISP=. VSE (mostly) does not. VSE determines >the correct setting at open
> > time. > How can it infer the difference between KEEP and DELETE?  (Or is
> > that the "mostly" part?) -- gil *
> >
> >
> >
> >
> > * --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email
> > to lists...@listserv.ua.edu  with the message:
> > INFO IBM-MAIN *
> >
>
>
>
> How does z/OS have a JCL DELETE option for a VSAM file? As far as I know,a
> VSAM file has to be explicitly DELETE/DEFINED using IDCAMS.
>
> --
> 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 JCl vs. VSE JCL: VSAM files

2018-07-10 Thread Farley, Peter x23353

z/OS DISP=(OLD,DELETE) works without any problem to delete a VSAM cluster that 
you own.  I use that JCL all the time to delete test VSAM files.

Creating a VSAM cluster may often require IDCAMS DEFINE, but the JCL LIKE 
parameter is your friend if for instance you are making a copy of a production 
file for a unit test run.  Just use the UNIT and SPACE parameters to allocate 
space and all else will be copied from the LIKE cluster.

Now if any of the LIKE cluster parameters are incompatible with your immediate 
need (REUSE vs NOREUSE perhaps, or LOG parameters for RLS) then you do need 
DEFINE, but the JCL DELETE works without an issue that I am aware of.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Wayne Bickerdike
Sent: Tuesday, July 10, 2018 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS JCl vs. VSE JCL: VSAM files

*How can it infer the difference between KEEP and DELETE?  (Or is thatthe
"mostly" part?)-- gil*

*On Wed, Jul 11, 2018 at 4:48 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu
<000433f07816-dmarc-requ...@listserv.ua.edu>> wrote:*
>
> *On Tue, 10 Jul 2018 14:23:34 -0400, Tony Thigpen wrote: > >Take a simple
> "I want to use a VSAM file". Here is what is normally used: >z/OS:
> >//POLYUPD  DD DSN=PROD.HKY.VSAM.HPP002P.F03,DISP=SHR >z/VSE: >// DLBL
> TEITEST,'TEI.TEST.VSAM',,VSAM,CAT=VSESPUC > >z/OS (mostly) requires a
> DISP=. VSE (mostly) does not. VSE determines >the correct setting at open
> time. > How can it infer the difference between KEEP and DELETE?  (Or is
> that the "mostly" part?) -- gil *

How does z/OS have a JCL DELETE option for a VSAM file? As far as I know,a
VSAM file has to be explicitly DELETE/DEFINED using IDCAMS.
--

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: z/OS JCl vs. VSE JCL: VSAM files

2018-07-10 Thread Wayne Bickerdike

*How can it infer the difference between KEEP and DELETE?  (Or is thatthe
"mostly" part?)-- gil*


*On Wed, Jul 11, 2018 at 4:48 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu
<000433f07816-dmarc-requ...@listserv.ua.edu>> wrote:*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *On Tue, 10 Jul 2018 14:23:34 -0400, Tony Thigpen wrote: > >Take a simple
> "I want to use a VSAM file". Here is what is normally used: >z/OS:
> >//POLYUPD  DD DSN=PROD.HKY.VSAM.HPP002P.F03,DISP=SHR >z/VSE: >// DLBL
> TEITEST,'TEI.TEST.VSAM',,VSAM,CAT=VSESPUC > >z/OS (mostly) requires a
> DISP=. VSE (mostly) does not. VSE determines >the correct setting at open
> time. > How can it infer the difference between KEEP and DELETE?  (Or is
> that the "mostly" part?) -- gil *
>
>
>
>
> * --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN *
>



How does z/OS have a JCL DELETE option for a VSAM file? As far as I know,a
VSAM file has to be explicitly DELETE/DEFINED using IDCAMS.

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

Re: NVAS admin panel issue

2018-07-10 Thread George Rodriguez

It's been a while since I made changes to the file used to capture
messages. Let me check and I'll get back to you.


*George Rodriguez*
*Specialist II - IT Solutions*
*IT Enterprise Applications*
*PX - 47652*
*(561) 357-7652 (office)*
*(954) 415-7586 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Eight Consecutive Years*


On Tue, Jul 10, 2018 at 11:46 AM saurabh khandelwal <
sourabhkhandelwal...@gmail.com> wrote:

> Hello George,
>
> Thanks for reply. But in netview, where will i find these message entry, so
> that I can delete.
>
> I looked over internet and found that using option 4, I can remove these LU
> but I am unable to get that panel.
>
> Can you please help me to drive this task .
>
> On Tue, Jul 10, 2018 at 6:32 PM, George Rodriguez <
> 016eebd7289b-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Instead of using ADM (used to administer applications and menu options of
> > NVAS) you have to use Netview on your NetView Application Selection Panel
> > and from there, you look for the message you want to suppress.
> >
> > *George Rodriguez*
> > *Specialist II - IT Solutions*
> > *IT Enterprise Applications*
> > *PX - 47652*
> > *(561) 357-7652 (office)*
> > *(954) 415-7586 (mobile)*
> > *School District of Palm Beach County*
> > *3348 Forest Hill Blvd.*
> > *Room B-251*
> > *West Palm Beach, FL. 33406-5869*
> > *Florida's Only A-Rated Urban District For Eight Consecutive Years*
> >
> >
> > On Tue, Jul 10, 2018 at 11:04 AM saurabh khandelwal <
> > sourabhkhandelwal...@gmail.com> wrote:
> >
> > > Hello Group,
> > >
> > >
> > > We getting below message frequently on our syslog
> > >
> > >
> > > EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXMAP  RC=1453
> > >
> > > EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXCICS RC=1453
> > >
> > > EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXMAP  RC=1453
> > >
> > > EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXCICS RC=1453
> > >
> > >
> > > I would like to remove these message and for doing this I logged into
> > NVAS
> > > but i m unable to get admin panel. . I just get parameter panel with
> adm
> > > command but I am unable to get the panel to delete these LU.
> > >
> > >
> > > when I type adm on main nvas screen , I get Maintain user parameters
> > > screen. I am unable to get this admin screen where i can use option 4
> to
> > > delete these unwanted LU.
> > >
> > >
> > >
> > >
> > >
> > > EMSPU1 Maintain User Parameters
> > >
> > >
> > >  sp;  GR Name :
> > > Terminal: A01IP449
> > >
> > > Application . . . ACB Name:  User . .:
> > > AS54
> > >
> > > Last Update  . .: Group. .:
> > > CRTGRP2
> > >
> > >& nbsp;
> > >  Default Group: Y
> > >
> > > Fill in or change the following:
> > >
> > >
> > >   Selection ID  . . . . . __   (1-99) Default Application _  (Y/N)
> > > ;
> > >
> > >   Msg. Received Indicator _(N=Normal/J=Jump/I=
> > > Information)
> > >
> > >   Jump Key  . . . . . . .  (PFnn/PAnn/ATTN)
> > >
> > >
> > >   Logon Profile . . . . . _(U=User/G=Group/S=System)
> > > p;
> > >
> > >   Active Profile  . . . . _(1/2) If User Profile
> > >
> > >
> > >   Profile 1 Comment . . . ___   Profile 2 Comment
> > > ___
> > >
> > >   Application ID Display  _(Y=Yes/N=No)
> > >
> > >
> > >
> > >
> > >
> > > Variables for Logon profile:
> > >  ;
> > >
> > >. . .    . .    . .
> > > 
> > >
> > >. .    . .    . .
> > > 
> > >
> > >. . .. . .. .
> > > .
> > >
> > >
> > >
> > >
> > > Enter a command: d (display), u (update), or l (list).
> > >
> > >
> > >
> > >
> > > Can anybody help me to remove these EMS0675E  message from NVAS
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> > --
> >
> >
> >
> >
> >
> >
> > *Disclaimer: *Under Florida law, e-mail addresses are public records.
> > If you do not want your e-mail address released in response to a public
> > records request, do not send electronic mail to this entity. Instead,
> > contact this office by phone or in writing.
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> Thanks & Regards
> Saurabh Khandelwal
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to

Re: DYNALLOC

2018-07-10 Thread Hobart Spitz

It beats the alternative.  The more I proofread, the more improvements I
make and the longer my posts get.  8-D

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Tue, Jul 10, 2018 at 2:41 PM, Peter Hunkeler  wrote:

> >> A minute AFTER I hit "send" for my message I saw the error.
>  >>
> >I do my best proofreading *after* I press the  key...
>
>
> I'm excellent at finding my typos when I read my post after it is echoed
> back to me.
>
>
> --
> Peter Hunkeler
>
>
>
> --
> 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: Adjust CSSMTP Translation Table

2018-07-10 Thread Roger Bolan

> I wanted to share the solution with you.
Thank you.

On Tue, Jul 10, 2018, 11:31 AM Kayhan Tanriverir <
01bdd42c15bc-dmarc-requ...@listserv.ua.edu> wrote:

> Hi,
> The problem is solved.
>
> CSSMTP fails to initialize when the  configuration file contains a
> TRANSLATE statement specifying a code page other than IBM-1047.
> Because the input buffer was not properly  initialized.  Applied PTF
> UI55791 solved the problem.
> CSSMTP has been corrected to initialize the input buffer used  for the
> conversion.
> It is enable IBM-1026 (Turkish code page) into the TRANSLATE statement in
> the CSSMTP configuration file.
>
> I wanted to share the solution with you.
>  Iyi calismalar, saygilar /
> Regards _
> Kayhan TANRIVERIR Senior Systems Programmer
> VBT Bilgi Teknolojileri A.S.
> www.vbt.com.tr
>
> Bu mesaj ve ekleri mesajda gönderildiği belirtilen kişi/kişilere özeldir
> ve gizlidir. Bu mesajın muhatabı olmamanıza rağmen tarafınıza ulaşmış
> olması halinde mesaj içeriğinin gizliliği ve bu gizlilik yükümlülüğüne
> uyulması zorunluluğu tarafınız için de söz konusudur. Mesaj ve eklerinde
> yer alan bilgilerin doğruluğu ve güncelliği konusunda gönderenin ya da
> şirketimizin herhangi bir sorumluluğu bulunmamaktadir. Şirketimiz mesajın
> ve bilgilerinin size değişikliğe uğrayarak veya geç ulaşmasından,
> bütünlüğünün ve gizliliğinin korunamamasından, virüs içermesinden ve
> bilgisayar sisteminize verebileceği herhangi bir zarardan sorumlu
> tutulamaz.
>
>  This message and attachments are confidential and intended solely for the
> individual(s) stated in this message. If you received this message although
> you are not the addressee you are responsible to keep the message
> confidential. The sender has no responsibility for the accuracy or
> correctness of the information in the message and its attachments. Our
> company shall have no liability for any changes or late receiving, loss of
> integrity and confidentiality, viruses and any damages caused in anyway to
> your computer 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: z/OS JCl vs. VSE JCL: VSAM files

2018-07-10 Thread Paul Gilmartin

On Tue, 10 Jul 2018 14:23:34 -0400, Tony Thigpen wrote:
>
>Take a simple "I want to use a VSAM file". Here is what is normally used:
>z/OS:
>//POLYUPD  DD DSN=PROD.HKY.VSAM.HPP002P.F03,DISP=SHR
>z/VSE:
>// DLBLTEITEST,'TEI.TEST.VSAM',,VSAM,CAT=VSESPUC
>
>z/OS (mostly) requires a DISP=. VSE (mostly) does not. VSE determines
>the correct setting at open time.
> 
How can it infer the difference between KEEP and DELETE?  (Or is that
the "mostly" part?)

-- gil

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

AW: Re: DYNALLOC

>> A minute AFTER I hit "send" for my message I saw the error.
 >>
>I do my best proofreading *after* I press the  key...


I'm excellent at finding my typos when I read my post after it is echoed back 
to me.


--
Peter Hunkeler



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

Re: load module loaded address between BPX LOAD (load_hfs) and ptrace+fork+exec?


>In a program, you can issue the BPX LOAD service to load a program
into memory... and similar to the LOAD macro, this returns the address
where the module was loaded, and the starting address.

>Now - is there any guarantee that if you then do a BPX FORK and then
a BPX EXEC to execute the module, that the module will be loaded at the same
address in the child?


The fork does a one by one copy of the address space (except from non-UNIXish 
things such as "DD allocations"). So the "BPX LOADed" load module is still at 
the same address. However, BPX EXEC is the equivalent of terminating the 
current job step, and starting a new job step where the BPX EXEC module will be 
the job step program.


I therefore say the answer is NO.


The only case where it could be loaded at the same address is when the BPX 
EXECed the load module is the same as the job step load module in the parent 
address space. But, I have never looked into an EXECed address space to see if 
that is the case or not.
 --
Peter Hunkeler

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

z/OS JCl vs. VSE JCL: VSAM files


I have a few minutes, so I thought I would make some more comments.

1) z/OS JCL statements are much more complex than z/VSE because they 
have a lot more 'options'. But, to be honest, most programmers just use 
a small sub-set of what they could use.


Take a simple "I want to use a VSAM file". Here is what is normally used:
z/OS:
//POLYUPD  DD DSN=PROD.HKY.VSAM.HPP002P.F03,DISP=SHR
z/VSE:
// DLBLTEITEST,'TEI.TEST.VSAM',,VSAM,CAT=VSESPUC

There are two major differences here:

z/OS (mostly) requires a DISP=. VSE (mostly) does not. VSE determines 
the correct setting at open time.


z/VSE (mostly) requires a CAT=. z/OS uses ICF catalogs and can figure it 
out by itself. This can be good or it can be bad. In z/VSE, almost every 
shop will have files with the same name located in different catalogs. 
This goes back to testing. With z/VSE, each partition (equal to a z/OS 
'initiator') can be set the same catalog name so that it points to a 
different physical catalog.


I can see some of you thinking: "That would make security impossible." 
No, it does not. z/VSE manages security based on not just file name, but 
catalog name.


Personally, I think the advantage is to z/VSE when using VSAM files. Of 
course, those of you that have never had the chance to test using 
different catalogs may understand it's advantage.


(Both z/OS and z/VSE can specify buffer space, which is about the only 
other option used on VSAM files, so that item is a wash.)



Next up will be non-VSAM files.

Tony Thigpen

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

Re: load module loaded address between BPX LOAD (load_hfs) and ptrace+fork+exec?

2018-07-10 Thread Charles Mills

I don't even play a UNIX expert on TV but doesn't FORK give the child a
total clone of the parent's address space? If X (for any X, including a load
module) was at address aaa before the FORK, will it not be at address aaa
for both parent and child after the FORK?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Thomas David Rivers
Sent: Tuesday, July 10, 2018 10:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: load module loaded address between BPX LOAD (load_hfs) and
ptrace+fork+exec?

In a program, you can issue the BPX LOAD service to load a program
into memory... and similar to the LOAD macro, this returns the address
where the module was loaded, and the starting address.

Now - is there any guarantee that if you then do a BPX FORK and then
a BPX EXEC to execute the module, that the module will be loaded at the same
address in the child?

If the child that is doing the BPX EXEC is running under PTRACE, does that
change things?

If there is such a guarantee, I can't seem to find it documented 
anywhere; any
pointers on that?

   - Thanks -
  - Dave Rivers -

-- 
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.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: NVAS admin panel issue

2018-07-10 Thread Elardus Engelbrecht

saurabh khandelwal wrote:

>We getting below message frequently on our syslog
>EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXMAP  RC=1453
>EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXCICS RC=1453
>EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXMAP  RC=1453
>EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXCICS RC=1453
>I would like to remove these message and for doing this I logged into NVAS but 
>i m unable to get admin panel.

How are you defined to NVAS? Are you a System Administrator?


>... I am unable to get the panel to delete these LU.

You do that first in VTAMLST dataset and then remove the applications which are 
using those LUs after bouncing NVAS.


>when I type adm on main nvas screen , I get Maintain user parameters screen. I 
>am unable to get this admin screen where i can use option 4 to delete these 
>unwanted LU.

Option 4 is NOT going to help you there. See above.

Groete / Greetings
Elardus Engelbrecht

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

Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

2018-07-10 Thread Seymour J Metz

It's not at all unusual that when you have experience with multiple systems, 
you find features on each that you wish you had on the others, e.g., in TSO I 
miss XEDIT.

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

From: IBM Mainframe Discussion List  on behalf of Tom 
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, July 10, 2018 11:58 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL 
replacement

On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris wrote:

>How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and
>successor compare with IBM z/OS JCL and with VSE JCL.  How does z/OS
>JCL compare with VSE JCL?  My memories of DOS360 JCL probably are
>irrelevant.

I worked on a Burroughs 1726 in the mid-1970's. It was an interesting machine
that included essentially the entire Master Control Program (MCP) that ran on
the bigger machines.

I remember that Work Flow Language was considerably more powerful than JCL,
but I don't remember any specifics. I had been working with JCL for a few years
at the time. I have a vague recollection that there were a few things that you
couldn't do in WFL that you could do in JCL.

I looked around on Bitsavers for a 1700 manual that covered WFL. I couldn't
find one, but I did find a 6700/7700 System Software Handbook that has a
section on WFL.
http://secure-web.cisco.com/1oaw3qgL4gjrPhX7F7mKUCWRYzVJCVNgBwvF4n69Tyh4AiTXZYpvdbYElQO_gQk39Aw8SKZL9EXHZxQC8j-HRQRZzE7dlu451IHUVHWRfCJtQ00yp5sP3tstyn70_nPF6jmBoZUYcr-9WsLkk3GQgxMPY6nEZ7ACnOrZvpA34fbcaetW1zYw5Vt6gheD3oNbMwgEhltw22YM32Lj5CJDN_QDcjNYf8R6VKTHVEi5KYN0IHZMPYXf6d4KjudGDEMh2PmecWl8oZZr2bOSkFLbzq-GZtvS0xmWFuKj3bPJz4GYa7E01_eypOi0haPjAeqCj29TtqDZUdB1Ll2lGlmMF1EAxNzR77A5iQsuvJgokfUnhlv2QGGJzURH-6JVXxr0GsisYrwaY1Mtu_nfA3YVqTsoVIEPHGfxK_tVzH728vEZ9fEh1KT3yQd3Qlw5rymmn/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fburroughs%2FB6500_6700%2F5000722_B6700_B7700_System_Software_Handbook_Jul73.pdf

I also found a Unisys Work Flow Language Manual at
https://secure-web.cisco.com/1kA_uHiE-G1A7sGXBC5HoPSMp5fW4vfvjFj5j9xycmrZNaam7iTrPXi7J99dfmimzEXSQCvlEIWLVYTmqWIi_ppQXx7EhcWis6req-sTPOZAtLv0v9Qab-cy0PPqtJh0w9WRFiLO0GI-HF9EeHHQY9Hs7Z8wJEhMidWMTfzD-ZjsEhgtvoWzsw6cuX_vykPZkrmb50ARjm-rUHSkpvXaO4ApAY8TlxyULBeNyd08Y93MMaAQmgInbaZZOrQO1V8Vauv4GVEj7FXBJktaBNDTPmQGKUqpiO7HrDzWMNzq30bqN4qf9bxz31b0FwUGcS-lX8Cz-q2tI3WODN3fH66YKPlgTQhaGIh2YS_4lLn_4DoGWpvvT2FdziNB9hASYBgAUHKxC0B8Gq2X3fkJ4LshGOKnFi07gS6IkA53XatQ5fEfg0YfePYAasZr35Bt2-9xP/https%3A%2F%2Fpublic.support.unisys.com%2Faseries%2Fdocs%2FClearPath-MCP-18.0%2F86001047-516

The 1700 was a very odd machine that allowed for bit-addressable memory.
While the physical memory was organized as 8-bit bytes, the higher level
languages all had their own "interpreter", each of which allowed for allocation
of storage on any bit boundary and with arbitrary bit length.

The interpreters were the microcode to support a given language. There
was one for Cobol, another for Fortran, and yet another for SDL. I
understood SDL to be a subset of Algol, and it was the language that
was used to write the MCP. Each interpreter was optimized for the
language that it was designed for.

Compiled instructions were of variable size, depending on the
requirements of the program. A program that referenced few data items
would need fewer bits in the instruction to reference those data items
than one that referenced many data items.

Pages were similarly variable in size, depending upon the requirements
of the program that was running.

Storage could be allocated in arbitrary increments. I did some
experimentation and IIRC, I found that I could do the equivalent of a
GETMAIN for 1 bit and it would be honored. Regardless of the size, a
48-bit header would be defined to describe it.

If you want a peek into this rather odd system, here is a link the the
1700 System Reference manual:
http://secure-web.cisco.com/1xDyW-vu-Dv_UI3m_YIQJyBu0rsCua4aPfkBHXhbwiEqORd0isbbjz6sSCQsVdHhy_byXdI4rVT8eMQuKWC6zUOyHFiBPgHbCaQV5cQaK1tUKYmbZGgUyC8iU0GJoabzUWpkjekGi_d2JeUMTeo5fKuAkD53eedbqjwOO0pptPzMhdOvO8PDyx9Lz3_rZcj_3K_nRedOxCGJIvvwDUJdwCuEgjFmJsM5TzBtdn-JUuqb2B8eGNqk5Jgn6AP8Vm5fBF-OAl1MVcSK-hD-Qb4pC8yCfWdUP1O063v3jnD1m_REvVUpw8XIoQdiZh5G0lqSbrv4QhaHN2FIS6BQ7tYiwFnzXPHJNHhsdA9xszkPt-qGD6qkgmFH5SZsBunPt153KglTNxPkHplpcUn0SDnEmo4DZQSeSKMP6djqSmI_Wbj9XjiuV8dFvpmJak0ssj7Zo/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fburroughs%2FB1700%2F1057155_B1700SysRefMan11-73.pdf

And for a peek into the Master Control Program, the MCP reference
manual can be found at:

Yan: Adjust CSSMTP Translation Table

2018-07-10 Thread Kayhan Tanriverir

Hi,
The problem is solved.

CSSMTP fails to initialize when the configuration file contains a TRANSLATE
statement specifying a code page other than IBM-1047.
Because the input buffer was not properly initialized. Applied PTF UI55791
solved the problem.
CSSMTP has been corrected to initialize the input buffer used for the
conversion.
It is enable IBM-1026 (Turkish code page) into the TRANSLATE statement in the
CSSMTP configuration file.

I wanted to share the solution with you.
Iyi calismalar, saygilar / Regards _
Kayhan TANRIVERIR Senior Systems Programmer
VBT Bilgi Teknolojileri A.S.
www.vbt.com.tr

Bu mesaj ve ekleri mesajda gönderildiği belirtilen kişi/kişilere özeldir ve
gizlidir. Bu mesajın muhatabı olmamanıza rağmen tarafınıza ulaşmış olması
halinde mesaj içeriğinin gizliliği ve bu gizlilik yükümlülüğüne uyulması
zorunluluğu tarafınız için de söz konusudur. Mesaj ve eklerinde yer alan
bilgilerin doğruluğu ve güncelliği konusunda gönderenin ya da şirketimizin
herhangi bir sorumluluğu bulunmamaktadir. Şirketimiz mesajın ve bilgilerinin
size değişikliğe uğrayarak veya geç ulaşmasından, bütünlüğünün ve gizliliğinin
korunamamasından, virüs içermesinden ve bilgisayar sisteminize verebileceği
herhangi bir zarardan sorumlu tutulamaz.

This message and attachments are confidential and intended solely for the
individual(s) stated in this message. If you received this message although you
are not the addressee you are responsible to keep the message confidential. The
sender has no responsibility for the accuracy or correctness of the information
in the message and its attachments. Our company shall have no liability for any
changes or late receiving, loss of integrity and confidentiality, viruses and
any damages caused in anyway to your computer system.

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

load module loaded address between BPX LOAD (load_hfs) and ptrace+fork+exec?

2018-07-10 Thread Thomas David Rivers


In a program, you can issue the BPX LOAD service to load a program
into memory... and similar to the LOAD macro, this returns the address
where the module was loaded, and the starting address.

Now - is there any guarantee that if you then do a BPX FORK and then
a BPX EXEC to execute the module, that the module will be loaded at the same
address in the child?

If the child that is doing the BPX EXEC is running under PTRACE, does that
change things?

If there is such a guarantee, I can't seem to find it documented 
anywhere; any

pointers on that?

  - Thanks -
 - Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

2018-07-10 Thread Tom Marchant

On Tue, 10 Jul 2018 10:28:05 -0500, John McKown wrote:

>I'm having a discussion on another,
>gaming, forum where one person insists that I simply can't be doing what I
>have been for about a month. Because I'm using a tool which "can't do
>that".

When my daughter was in high school she wrote a version of Space Invaders 
for the TI-84 graphing calculator. She learned a lot about optimizing code for 
performance with that project.

-- 
Tom Marchant

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

Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

2018-07-10 Thread Tom Marchant

On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris wrote:

>How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and
>successor compare with IBM z/OS JCL and with VSE JCL. How does z/OS
>JCL compare with VSE JCL? My memories of DOS360 JCL probably are
>irrelevant.

I worked on a Burroughs 1726 in the mid-1970's. It was an interesting machine
that included essentially the entire Master Control Program (MCP) that ran on
the bigger machines.

I remember that Work Flow Language was considerably more powerful than JCL,
but I don't remember any specifics. I had been working with JCL for a few years
at the time. I have a vague recollection that there were a few things that you
couldn't do in WFL that you could do in JCL.

I looked around on Bitsavers for a 1700 manual that covered WFL. I couldn't
find one, but I did find a 6700/7700 System Software Handbook that has a
section on WFL.
http://bitsavers.trailing-edge.com/pdf/burroughs/B6500_6700/5000722_B6700_B7700_System_Software_Handbook_Jul73.pdf

I also found a Unisys Work Flow Language Manual at
https://public.support.unisys.com/aseries/docs/ClearPath-MCP-18.0/86001047-516

The 1700 was a very odd machine that allowed for bit-addressable memory.
While the physical memory was organized as 8-bit bytes, the higher level
languages all had their own "interpreter", each of which allowed for allocation
of storage on any bit boundary and with arbitrary bit length.

The interpreters were the microcode to support a given language. There
was one for Cobol, another for Fortran, and yet another for SDL. I
understood SDL to be a subset of Algol, and it was the language that
was used to write the MCP. Each interpreter was optimized for the
language that it was designed for.

Compiled instructions were of variable size, depending on the
requirements of the program. A program that referenced few data items
would need fewer bits in the instruction to reference those data items
than one that referenced many data items.

Pages were similarly variable in size, depending upon the requirements
of the program that was running.

Storage could be allocated in arbitrary increments. I did some
experimentation and IIRC, I found that I could do the equivalent of a
GETMAIN for 1 bit and it would be honored. Regardless of the size, a
48-bit header would be defined to describe it.

If you want a peek into this rather odd system, here is a link the the
1700 System Reference manual:
http://bitsavers.trailing-edge.com/pdf/burroughs/B1700/1057155_B1700SysRefMan11-73.pdf

And for a peek into the Master Control Program, the MCP reference
manual can be found at:
http://bitsavers.trailing-edge.com/pdf/burroughs/B1700/1088010B_1700MCPRefManAug75.pdf

Perhaps another time I will tell the tale of what we bought the
computer for and what happened with it.

--
Tom Marchant

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

Re: NVAS admin panel issue

2018-07-10 Thread saurabh khandelwal

Hello George,

Thanks for reply. But in netview, where will i find these message entry, so
that I can delete.

I looked over internet and found that using option 4, I can remove these LU
but I am unable to get that panel.

Can you please help me to drive this task .

On Tue, Jul 10, 2018 at 6:32 PM, George Rodriguez <
016eebd7289b-dmarc-requ...@listserv.ua.edu> wrote:

> Instead of using ADM (used to administer applications and menu options of
> NVAS) you have to use Netview on your NetView Application Selection Panel
> and from there, you look for the message you want to suppress.
>
> *George Rodriguez*
> *Specialist II - IT Solutions*
> *IT Enterprise Applications*
> *PX - 47652*
> *(561) 357-7652 (office)*
> *(954) 415-7586 (mobile)*
> *School District of Palm Beach County*
> *3348 Forest Hill Blvd.*
> *Room B-251*
> *West Palm Beach, FL. 33406-5869*
> *Florida's Only A-Rated Urban District For Eight Consecutive Years*
>
>
> On Tue, Jul 10, 2018 at 11:04 AM saurabh khandelwal <
> sourabhkhandelwal...@gmail.com> wrote:
>
> > Hello Group,
> >
> >
> > We getting below message frequently on our syslog
> >
> >
> > EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXMAP  RC=1453
> >
> > EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXCICS RC=1453
> >
> > EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXMAP  RC=1453
> >
> > EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXCICS RC=1453
> >
> >
> > I would like to remove these message and for doing this I logged into
> NVAS
> > but i m unable to get admin panel. . I just get parameter panel with adm
> > command but I am unable to get the panel to delete these LU.
> >
> >
> > when I type adm on main nvas screen , I get Maintain user parameters
> > screen. I am unable to get this admin screen where i can use option 4 to
> > delete these unwanted LU.
> >
> >
> >
> >
> >
> > EMSPU1 Maintain User Parameters
> >
> >
> >  sp;  GR Name :
> > Terminal: A01IP449
> >
> > Application . . . ACB Name:  User . .:
> > AS54
> >
> > Last Update  . .: Group. .:
> > CRTGRP2
> >
> >& nbsp;
> >  Default Group: Y
> >
> > Fill in or change the following:
> >
> >
> >   Selection ID  . . . . . __   (1-99) Default Application _  (Y/N)
> > ;
> >
> >   Msg. Received Indicator _(N=Normal/J=Jump/I=
> > Information)
> >
> >   Jump Key  . . . . . . .  (PFnn/PAnn/ATTN)
> >
> >
> >   Logon Profile . . . . . _(U=User/G=Group/S=System)
> > p;
> >
> >   Active Profile  . . . . _(1/2) If User Profile
> >
> >
> >   Profile 1 Comment . . . ___   Profile 2 Comment
> > ___
> >
> >   Application ID Display  _(Y=Yes/N=No)
> >
> >
> >
> >
> >
> > Variables for Logon profile:
> >  ;
> >
> >. . .    . .    . .
> > 
> >
> >. .    . .    . .
> > 
> >
> >. . .. . .. .
> > .
> >
> >
> >
> >
> > Enter a command: d (display), u (update), or l (list).
> >
> >
> >
> >
> > Can anybody help me to remove these EMS0675E  message from NVAS
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
>
>
>
>
>
>
> *Disclaimer: *Under Florida law, e-mail addresses are public records.
> If you do not want your e-mail address released in response to a public
> records request, do not send electronic mail to this entity. Instead,
> contact this office by phone or in writing.
>
>
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Thanks & Regards
Saurabh Khandelwal

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

Re: NVAS admin panel issue

2018-07-10 Thread George Rodriguez

Instead of using ADM (used to administer applications and menu options of
NVAS) you have to use Netview on your NetView Application Selection Panel
and from there, you look for the message you want to suppress.

*George Rodriguez*
*Specialist II - IT Solutions*
*IT Enterprise Applications*
*PX - 47652*
*(561) 357-7652 (office)*
*(954) 415-7586 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Eight Consecutive Years*


On Tue, Jul 10, 2018 at 11:04 AM saurabh khandelwal <
sourabhkhandelwal...@gmail.com> wrote:

> Hello Group,
>
>
> We getting below message frequently on our syslog
>
>
> EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXMAP  RC=1453
>
> EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXCICS RC=1453
>
> EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXMAP  RC=1453
>
> EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXCICS RC=1453
>
>
> I would like to remove these message and for doing this I logged into NVAS
> but i m unable to get admin panel. . I just get parameter panel with adm
> command but I am unable to get the panel to delete these LU.
>
>
> when I type adm on main nvas screen , I get Maintain user parameters
> screen. I am unable to get this admin screen where i can use option 4 to
> delete these unwanted LU.
>
>
>
>
>
> EMSPU1 Maintain User Parameters
>
>
>  sp;  GR Name :
> Terminal: A01IP449
>
> Application . . . ACB Name:  User . .:
> AS54
>
> Last Update  . .: Group. .:
> CRTGRP2
>
>& nbsp;
>  Default Group: Y
>
> Fill in or change the following:
>
>
>   Selection ID  . . . . . __   (1-99) Default Application _  (Y/N)
> ;
>
>   Msg. Received Indicator _(N=Normal/J=Jump/I=
> Information)
>
>   Jump Key  . . . . . . .  (PFnn/PAnn/ATTN)
>
>
>   Logon Profile . . . . . _(U=User/G=Group/S=System)
> p;
>
>   Active Profile  . . . . _(1/2) If User Profile
>
>
>   Profile 1 Comment . . . ___   Profile 2 Comment
> ___
>
>   Application ID Display  _(Y=Yes/N=No)
>
>
>
>
>
> Variables for Logon profile:
>  ;
>
>. . .    . .    . .
> 
>
>. .    . .    . .
> 
>
>. . .. . .. .
> .
>
>
>
>
> Enter a command: d (display), u (update), or l (list).
>
>
>
>
> Can anybody help me to remove these EMS0675E  message from NVAS
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

-- 






*Disclaimer: *Under Florida law, e-mail addresses are public records. 
If you do not want your e-mail address released in response to a public 
records request, do not send electronic mail to this entity. Instead, 
contact this office by phone or in writing.








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

Re: REXX as JCL replacement

2018-07-10 Thread Roger W Suhr

I agree with David Crayford's comment, 100%!
Let's put this to rest.  To completely replace JCL with REXX is not an option.  
If you want to run certain applications driven by REXX program, by my guest, 
that's a design issue.  But please don't plan on replacing everything with REXX.

Roger W. Suhr
suhr...@gmail.com


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Monday, July 9, 2018 21:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement

On 10/07/2018 7:15 AM, Andrew Rowley wrote:
> On 9/07/2018 10:46 PM, Hobart Spitz wrote:
>>
>> Basically, JCL is so far from real a programming language, that I 
>> can't describe it.
>>
> That's because JCL isn't a programming language. There are plenty of 
> other languages that also suck as programming languages e.g. HTML, 
> XML, JSON, but that's not what they are supposed to be.


Java Batch (JSR 352) has basically re-implemented JCL using XML. Now that must 
really suck!


>
> JCL is really a kind of definition language. In programming language 
> terms it is more like a set of classes in OOP than a language in 
> itself: you have a job, which has steps, steps have DDs etc. The 
> syntax is old fashioned, but the concepts are very much OOP. It would 
> be relatively simple to create a set of classes in your OOP language 
> of choice to hide the syntax - just create a Job object, add Step 
> objects, add DataDefinition objects etc. and have a Submit method emit 
> JCL.
>
> If I want to write a program, I will choose a programming language. If 
> I want to define a unit of work to the system, JCL does a pretty good 
> job. I definitely prefer JCL to long command lines with multiple 
> switches and options defining input and output files, which is the 
> non-z/OS equivalent.
>
> Andrew Rowley
> Black Hill Software
>
> --
> 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: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

2018-07-10 Thread John McKown

On Tue, Jul 10, 2018 at 10:19 AM Seymour J Metz  wrote:

> It wouldn't help; lots of people don't know what they platform that they
> are running on can do, much less other platforms. If I had $1 for every
> time somebody told me that, e.g., ISPF, couldn't do that I'd been doing for
> decades ...
>

Yeah, it applies to live in general. I'm having a discussion on another,
gaming, forum where one person insists that I simply can't be doing what I
have been for about a month. Because I'm using a tool which "can't do
that".

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

-- 
There is no such thing as the Cloud. It is just somebody else’s computer.

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: REXX as JCL replacement

2018-07-10 Thread Seymour J Metz

> Seymour, I have to interject here and state that I like JCL.

De Gustibus Non Est Disputandum  said the old lady as she kissed the cow. For 
me it's more like the water in Gunga Din.

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

From: IBM Mainframe Discussion List  on behalf of 
Ward Able, Grant 
Sent: Tuesday, July 10, 2018 5:12 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement

Seymour, I have to interject here and state that I like JCL. There - it is out 
in the open and I feel much better for having said it :-)
I am not going to say that it cannot be improved, of course it can, but I think 
it is a wonderful tool that has grown over the years, while HAVING to maintain 
most backward compatibility so it seems limited in how it can change, because 
of the need to maintain that compatibility.

Regards - Grant

DTCC Internal (Green)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: 09 July 2018 16:10
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement

ATTENTION! This email originated outside of DTCC; exercise caution.

 1. I don't recall anybody on IBM-MAIN claims that JCL is good.

 2. Creative solutions are good if they solve the actual problem, not
just an imaginary or irrelevant one.

 2. Sleep does not address the deadly embrace problem.

 3. PDSE does not solve the problem.

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

From: IBM Mainframe Discussion List  on behalf of 
Hobart Spitz 
Sent: Monday, July 9, 2018 8:46 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement

Ward wrote:
>What are the problems (perceived or real) that will be resolved by
replacing JCL with REXX?

I think that it's important to first understand the characteristics on which 
many people base their thinking that JCL is good and may never go away.  The 
point is important, and the basis is a valid concern.  The conclusion is wrong. 
 All it takes is understanding the problem and coming up with creative 
solutions.  As I describe below, DB2 based applications and those that use only 
PDSEs are likely to be good starting points.

One valuable feature of z/OS batch processing is that all ENQs for the entire 
JOB are obtained before any step execution actually starts.  This is done to 
prevent a deadly embrace:  JOB A has exclusive access to dataset X and needs 
exclusive access to dataset Y.  JOB B has access to Y and needs exclusive on X. 
 Neither JOB can proceed until one is canceled, resulting in lost production.  
Despite this being a useful service, there is no TSO equivalent, either via a 
parallel ENQs (as Seymour suggested) or a standard SLEEP mechanism to allow for 
retries.

Other repliers have answered Ward's question well, I was going to cut some of 
the text out of my draft, but didn't.  I think it is important to understand 
what z/OS batch processing does, and where possible, why, so we don't 
trivialize the effort or miss easy opportunities.  I'll share my best educated 
guesses with respect to the subject at hand.

When a batch JOB becomes eligible for execution these actions, relevant to our 
subject, happen in this order:

   1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
   merged with the submitted JCL.  These are necessary for #2 below.
   2. Substitutions are processed.  This is needed for #3; if DSNs could
   change later, via substitution or IF, the ENQs would be incorrect.
   3. ENQs are obtained on all datasets.
   4. The EXECs for PGMs are processed, in order, one at a time.

So any REXX implementation would have either to forgo do initial ENQs, or 
commit to not changing DSNs during processing, or observe certain conventions.  
These conventions could include the following, one or the other may be 
appropriate depending on the applications' needs:

   - Perform ENQs in a consistent order.  (Left as an exercise for the
   reader.  :-)  )
   - Do all ALLOCations up front, and free all exclusive allocations before
   a second set of ENQs is requested.
   - Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
   or ALLOC failure, and taking appropriate action to recover/restart/suspend
   processing.  Initial ENQs are not required.  If implemented via a common
   routine, either site or vendor provided, this could be more viable.  A
   little additional coding to support automated restart might be needed; see
   also below on my first attempt at using REXX instead of JCL.
   - Something else.

It might be helpful to know if, with all the changes and advancements, 
deadly-embraces are still the issue it was in the 1960s-1980s.  As I explain 
below, an application that does not update any sequential datasets or PDSs, 
does not have this as a major concern.  E.g. an application where all data 
updates are done to DB2

Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

2018-07-10 Thread Dana Mitchell

Like I said, I was using cards when I last worked on VSE, so it's been a little 
while... ;)
I'll be curious to hear whats changed too

Dana 

On Tue, 10 Jul 2018 09:15:57 -0400, Tony Thigpen  wrote:

>I wish those of you not current on VSE would remember that we have had
>just as many years to change things as z/OS has. Oh, wait, we have
>longer.
>
>Later, when I have time, I will list some of those things.
>
>Tony Thigpen
>

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

Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

2018-07-10 Thread Seymour J Metz

It wouldn't help; lots of people don't know what they platform that they are 
running on can do, much less other platforms. If I had $1 for every time 
somebody told me that, e.g., ISPF, couldn't do that I'd been doing for decades 
...

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

From: IBM Mainframe Discussion List  on behalf of 
Tony Thigpen 
Sent: Tuesday, July 10, 2018 9:15 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL 
replacement

I wish those of you not current on VSE would remember that we have had
just as many years to change things as z/OS has. Oh, wait, we have
longer. DOS came out before what ever MVS was called back then.

z/VSE has a lot of things in the JCL that z/OS has no equal to. I work
both areas and there are many things in z/VSE that I miss in z/OS. There
are also some things in z/OS that are not in z/VSE, but the last z/VSE
to z/OS conversion I did, the client programmers hated the 'limitations'
they found in z/OS and had to go do a lot of program changes due to
these limits.

Later, when I have time, I will list some of those things.

Tony Thigpen

ITschak Mugzach wrote on 07/10/2018 08:46 AM:
> ... And I may add that if VSE JCL was so good, it wouldn't have so many
> private extensions (and I've seem some of them).
>
> ITschak
>
> On Tue, Jul 10, 2018 at 2:37 PM Dana Mitchell  wrote:
>
>> My memories of VSE JCL are dated, and quite possbily incorrect with
>> current VSE, but I recall that I felt it was more complicated that MVS
>> jcl.  It had more types of statements (although fewer parms per type),
>>   JOB, * $$ JOB,  UPSI, OPTION, LIBDEF,  PAUSE, and EXEC statements.   To
>> describe a disk file, potentially required at least 3 statements,  ASSIGN,
>> DLBL, and EXTENT.  Tape required ASSIGN and TLBL,  tape, disk and inline
>> files were not interchangeable as far as programs were concerned.
>>
>> An interesting 'feature' was that syntax checking was done at execution
>> time, so when a JCL error was encountered, a console message was issued
>> that required a reply,  allowing you to retype the errant statement.  So in
>> the days of real card readers, if you needed to make a quick one time
>> change to a job, you could just flip the card around backwards, causing
>> 'Invalid Statement' console message prompt,  allowing you to type in the
>> statement you really wanted.
>>
>> Dana
>>
>> On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris 
>> wrote:
>>> How does z/OS JCL compare with VSE JCL?  My memories of DOS360 JCL
>> probably are
>>> irrelevant.
>>>
>>> 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

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

NVAS admin panel issue

2018-07-10 Thread saurabh khandelwal

Hello Group,


We getting below message frequently on our syslog


EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXMAP  RC=1453

EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXCICS RC=1453

EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXMAP  RC=1453

EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXCICS RC=1453


I would like to remove these message and for doing this I logged into NVAS
but i m unable to get admin panel. . I just get parameter panel with adm
command but I am unable to get the panel to delete these LU.


when I type adm on main nvas screen , I get Maintain user parameters
screen. I am unable to get this admin screen where i can use option 4 to
delete these unwanted LU.





EMSPU1 Maintain User Parameters


 sp;  GR Name :
Terminal: A01IP449

Application . . . ACB Name:  User . .:
AS54

Last Update  . .: Group. .:
CRTGRP2

   & nbsp;
 Default Group: Y

Fill in or change the following:


  Selection ID  . . . . . __   (1-99) Default Application _  (Y/N)
;

  Msg. Received Indicator _(N=Normal/J=Jump/I=
Information)

  Jump Key  . . . . . . .  (PFnn/PAnn/ATTN)


  Logon Profile . . . . . _(U=User/G=Group/S=System)
p;

  Active Profile  . . . . _(1/2) If User Profile


  Profile 1 Comment . . . ___   Profile 2 Comment
___

  Application ID Display  _(Y=Yes/N=No)





Variables for Logon profile:
 ;

   . . .    . .    . .


   . .    . .    . .


   . . .. . .. .
.




Enter a command: d (display), u (update), or l (list).




Can anybody help me to remove these EMS0675E  message from NVAS

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

Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS MANAGED DISK

2018-07-10 Thread John Dawes

 You mention "bypass options".  Does this pertain to recalling the file to a 
non-SMS disk or SMS disk?  I would like to try out your suggestion.  
On Friday, 6 July 2018, 2:53:13 pm GMT-4, Gibney, Dave  
wrote:  
 
 There are bypass options, given sufficient authority. Of course, with 
sufficient authority, the ACS routines could be tweaked for the specific case 
during recall. :)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Allan Staller
> Sent: Friday, July 06, 2018 11:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS
> MANAGED DISK
> 
> I don't think ADRDSSU will override the SMS specifications.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gibney, Dave
> Sent: Friday, July 6, 2018 1:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS
> MANAGED DISK
> 
> 1. Pull it back. 2. Move it with ADDRDSSU
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Mike Schwab
> > Sent: Friday, July 06, 2018 11:24 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS
> > MANAGED DISK
> >
> > If that dataset needs a large allocation, quiesce a/that volume,
> > migrate the select volume to move unallocated datasets on it, defrag
> > to create larger extents, then recall it.  If no active volume has
> > enough space, it would go there.
> > On Fri, Jul 6, 2018 at 10:07 AM John Dawes <00ff0e22811f-dmarc-
> > requ...@listserv.ua.edu> wrote:
> > >
> > >  Allan,
> > > Thanks for your suggestion.  I looked at that option however being
> > > in the
> > Production cycle window I cannot do so because jobs could abend if I
> > do a DISNEW.
> > >    On Friday, 6 July 2018, 11:00:02 am GMT-4, Allan Staller
> >  wrote:
> > >
> > >  AFAIK, Guaranteed Space only (IMO) acceptable way to accomplish
> > > what
> > you've described.
> > >
> > > You could place all of the other volumes in the pool in QUIESCE or
> > > DISNEW
> > for the duration (IMO, not acceptable).
> > > You could make the ACS routine and SMS update to place the desired
> > > volume in its own SG, restore your data, and reverse the process.
> > > (Waaay tooo much work!)
> > >
> > > HTH,
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes
> > > Sent: Friday, July 6, 2018 9:48 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS
> > MANAGED
> > > DISK
> > >
> > > G'Day,
> > > Because of storage considerations I would like to recall some ML2
> > > SMS
> > managed dsns to a specific SMS managed disk.  I tried a few things e.g.
> > :HSEND RECALL 'CICSV2.XPD2.A7060.ZFE1' VOLUME(ZFE315) -  UNIT(3390)
> > However the dsn was not recalled to the desired disk.  I thought of
> > using the GUARANTEED SPACE storage class option as a work around.  I
> > checked the doc (DFSMShsm Storage Administration Guide) but I could
> > not find an example.  Is this possible to do?  If so, would anyone
> > have an example to share?
> > > Thanks.
> > >
> > > 
> > > -- 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

Re: New OSA cards?

2018-07-10 Thread Clark Morris

[Default] On 10 Jul 2018 07:05:11 -0700, in bit.listserv.ibm-main
r.skoru...@bremultibank.com.pl (R.S.) wrote:

>S>I just read Announcement Letter from IBM, Power machines now have 
>network interface cards 40GbE, two interfaces per card.
>In PC server world such card have been available for while, even 100Gbps 
>cards are present.
>
>What about System Z?ounds like no such option.
>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ioaz100/ioaz100_OSA-Express6S.htm
>There are 10GbE, 1GbE and 1000BaseT options.
>Note there're also RoCE and RoCE2 cards, but both are 10Gbps.

Combining your 2 posts, I suspect that IBM z communication group has
struck out again.

Clark Morris

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

Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

2018-07-10 Thread Clark Morris

[Default] On 10 Jul 2018 06:16:08 -0700, in bit.listserv.ibm-main
t...@vse2pdf.com (Tony Thigpen) wrote:

>I wish those of you not current on VSE would remember that we have had 
>just as many years to change things as z/OS has. Oh, wait, we have 
>longer. DOS came out before what ever MVS was called back then.
>
>z/VSE has a lot of things in the JCL that z/OS has no equal to. I work 
>both areas and there are many things in z/VSE that I miss in z/OS. There 
>are also some things in z/OS that are not in z/VSE, but the last z/VSE 
>to z/OS conversion I did, the client programmers hated the 'limitations' 
>they found in z/OS and had to go do a lot of program changes due to 
>these limits.
>
>Later, when I have time, I will list some of those things.

Thes could and should lead to some RFEs being submitted.  

Clark Morris
>
>Tony Thigpen
>
>ITschak Mugzach wrote on 07/10/2018 08:46 AM:
>> ... And I may add that if VSE JCL was so good, it wouldn't have so many
>> private extensions (and I've seem some of them).
>> 
>> ITschak
>> 
>> On Tue, Jul 10, 2018 at 2:37 PM Dana Mitchell  wrote:
>> 
>>> My memories of VSE JCL are dated, and quite possbily incorrect with
>>> current VSE, but I recall that I felt it was more complicated that MVS
>>> jcl.  It had more types of statements (although fewer parms per type),
>>>   JOB, * $$ JOB,  UPSI, OPTION, LIBDEF,  PAUSE, and EXEC statements.   To
>>> describe a disk file, potentially required at least 3 statements,  ASSIGN,
>>> DLBL, and EXTENT.  Tape required ASSIGN and TLBL,  tape, disk and inline
>>> files were not interchangeable as far as programs were concerned.
>>>
>>> An interesting 'feature' was that syntax checking was done at execution
>>> time, so when a JCL error was encountered, a console message was issued
>>> that required a reply,  allowing you to retype the errant statement.  So in
>>> the days of real card readers, if you needed to make a quick one time
>>> change to a job, you could just flip the card around backwards, causing
>>> 'Invalid Statement' console message prompt,  allowing you to type in the
>>> statement you really wanted.
>>>
>>> Dana
>>>
>>> On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris 
>>> wrote:
 How does z/OS JCL compare with VSE JCL?  My memories of DOS360 JCL
>>> probably are
 irrelevant.

 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

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

Re: IXC344I send cnt: when does it wrap?

2018-07-10 Thread Vernooij, Kees (ITOPT1) - KLM

Thanks Mark!

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mark A. Brooks
> Sent: 10 July, 2018 15:51
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IXC344I send cnt: when does it wrap?
> 
> The signal counts are 4 byte counters, they'll wrap to zero after they
> reach 4,294,967,295.
> 
> My guess is that the authors of the Redbook saw that the IXC344I msg
> allowed 10 bytes for the counter and assumed that the output would be
> delimited with commas.  But it's not.
> 
> --Mark Brooks
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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



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

Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement


W dniu 2018-07-10 o 15:15, Tony Thigpen pisze:
I wish those of you not current on VSE would remember that we have had 
just as many years to change things as z/OS has. Oh, wait, we have 
longer. DOS came out before what ever MVS was called back then.


z/VSE has a lot of things in the JCL that z/OS has no equal to. I work 
both areas and there are many things in z/VSE that I miss in z/OS. 
There are also some things in z/OS that are not in z/VSE, but the last 
z/VSE to z/OS conversion I did, the client programmers hated the 
'limitations' they found in z/OS and had to go do a lot of program 
changes due to these limits.


Later, when I have time, I will list some of those things.

Please, do. It will be interesting.
Personally I don't know VSE, but heard about very few VSE advantages.



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


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

Re: New OSA cards?


Sounds like no such option.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ioaz100/ioaz100_OSA-Express6S.htm
There are 10GbE, 1GbE and 1000BaseT options.
Note there're also RoCE and RoCE2 cards, but both are 10Gbps.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-07-10 o 15:13, Allan Staller pisze:

Sounds like old news to me. OSA-6 cards are both faster that 40Gbps and offer 
at least 4 ports/card. IIRC.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, July 10, 2018 7:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: New OSA cards?

I just read Announcement Letter from IBM, Power machines now have network 
interface cards 40GbE, two interfaces per card.
In PC server world such card have been available for while, even 100Gbps cards 
are present.

What about System Z?

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


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

AW: Re: Primary & secondary space values in DFSORT's dynamic work space allocation.


>It might be worth pointing out what might be a little known fact[snip]


Thanks, I do understand this. Nevertheless, good point. Worth to be found in 
the archives.



>If you think specifying FILSZ might help,... [snip]



I do think so, indeed, but I talked to the application people and the have now 
way to tell and pass to sort in this case.


BTW, I worth a test program meanwhile and found that the manual and the reality 
diverge. I'm pursuing this offline and will report back once I now more.


--
Peter Hunkeler



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

Re: IXC344I send cnt: when does it wrap?

2018-07-10 Thread Mark A. Brooks

The signal counts are 4 byte counters, they'll wrap to zero after they reach 
4,294,967,295.

My guess is that the authors of the Redbook saw that the IXC344I msg allowed 10 
bytes for the counter and assumed that the output would be delimited with 
commas.  But it's not.  

--Mark Brooks

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

Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

2018-07-10 Thread John McKown

On Tue, Jul 10, 2018 at 8:16 AM Tony Thigpen  wrote:

> I wish those of you not current on VSE would remember that we have had
> just as many years to change things as z/OS has. Oh, wait, we have
> longer. DOS came out before what ever MVS was called back then.
>

OS/360 -- either MFT or MVT.



>
> z/VSE has a lot of things in the JCL that z/OS has no equal to. I work
> both areas and there are many things in z/VSE that I miss in z/OS. There
> are also some things in z/OS that are not in z/VSE, but the last z/VSE
> to z/OS conversion I did, the client programmers hated the 'limitations'
> they found in z/OS and had to go do a lot of program changes due to
> these limits.
>
> Later, when I have time, I will list some of those things.
>

I think that would be very interesting. I am eagerly awaiting.



>
> Tony Thigpen
>

-- 
There is no such thing as the Cloud. It is just somebody else’s computer.

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] Re: remove bad GDG entry from GDG base

2018-07-10 Thread Nelson, Judith

Hi, 
We finally were able to remove the bad with the help of TREX. 
We were able to list the GDG GAT entries with TREX. After sending them the 
listings, they created a Zap for us to delete the entry. 

I executed the zap and was able to create the entry the right way, it rolled 
right in. :) 

This was something new to me. I guess I didn't know that when creating a GDG 
entry that the system rolled it in first and then catalogs it. Also didn't know 
about GAT entries. 
Every day you learn something new. :) 

Thanks everybody for your input. 

Judith Nelson  | Senior Systems Programmer 
Sammons® Financial Group Member Companies
One Sammons Plaza  | Sioux Falls, SD 57193 
Phone: (605) 373-2321 
jnel...@sfgmembers.com 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Burrell, Todd
Sent: Saturday, July 7, 2018 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: remove bad GDG entry from GDG base

Have you tried DELETE dsn NSCR or just putting a U beside the entry in an ISPF 
3.4 listing? 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Thursday, July 05, 2018 5:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: remove bad GDG entry from GDG base

We tried. :(

   DELETE PTP.DP.TRMS.ARCH999.X3.G0308V00 FILE(VOL2) NVR

IDC3014I CATALOG ERROR

IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLE3-92

IDC0551I ** ENTRY PTP.DP.TRMS.ARCH999.X3.G0308V00 NOT DELETED

IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8

Judith Nelson  | Senior Systems Programmer Sammons® Financial Group Member 
Companies One Sammons Plaza  | Sioux Falls, SD 57193
Phone: (605) 373-2321
jnel...@sfgmembers.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, July 5, 2018 10:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: remove bad GDG entry from GDG base

On Thu, 5 Jul 2018 09:27:07 -0500, Brad Wissink wrote:

>We need to remove a GDG entry from a GDG base, but the catalog entry

>doesn't exist.  What happened was that during the creation of the GDG

>(PTP.DP.TRMS.ARCH999.X3.G0308V00) the user catalog filled up and could

>not extend.

I suspect that the NVR was created in the VVDS. I would try DELETE NVR, 
followed by DEFINE.

--

Tom Marchant

--

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

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information intended only for the use of the 
intended addressee. Any dissemination, distribution, copying or action taken in 
reliance on the contents of this email by anyone other than the intended 
recipient is strictly prohibited. If you have received this email in error 
please immediately delete it and notify sender at the above CSX email address. 
Sender and CSX accept no liability for any damage caused directly or indirectly 
by receipt of this email.

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

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic

Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

I wish those of you not current on VSE would remember that we have had 
just as many years to change things as z/OS has. Oh, wait, we have 
longer. DOS came out before what ever MVS was called back then.


z/VSE has a lot of things in the JCL that z/OS has no equal to. I work 
both areas and there are many things in z/VSE that I miss in z/OS. There 
are also some things in z/OS that are not in z/VSE, but the last z/VSE 
to z/OS conversion I did, the client programmers hated the 'limitations' 
they found in z/OS and had to go do a lot of program changes due to 
these limits.


Later, when I have time, I will list some of those things.

Tony Thigpen

ITschak Mugzach wrote on 07/10/2018 08:46 AM:

... And I may add that if VSE JCL was so good, it wouldn't have so many
private extensions (and I've seem some of them).

ITschak

On Tue, Jul 10, 2018 at 2:37 PM Dana Mitchell  wrote:


My memories of VSE JCL are dated, and quite possbily incorrect with
current VSE, but I recall that I felt it was more complicated that MVS
jcl.  It had more types of statements (although fewer parms per type),
  JOB, * $$ JOB,  UPSI, OPTION, LIBDEF,  PAUSE, and EXEC statements.   To
describe a disk file, potentially required at least 3 statements,  ASSIGN,
DLBL, and EXTENT.  Tape required ASSIGN and TLBL,  tape, disk and inline
files were not interchangeable as far as programs were concerned.

An interesting 'feature' was that syntax checking was done at execution
time, so when a JCL error was encountered, a console message was issued
that required a reply,  allowing you to retype the errant statement.  So in
the days of real card readers, if you needed to make a quick one time
change to a job, you could just flip the card around backwards, causing
'Invalid Statement' console message prompt,  allowing you to type in the
statement you really wanted.

Dana

On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris 
wrote:

How does z/OS JCL compare with VSE JCL?  My memories of DOS360 JCL

probably are

irrelevant.

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

Re: New OSA cards?

2018-07-10 Thread Allan Staller

Sounds like old news to me. OSA-6 cards are both faster that 40Gbps and offer 
at least 4 ports/card. IIRC.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, July 10, 2018 7:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: New OSA cards?

I just read Announcement Letter from IBM, Power machines now have network 
interface cards 40GbE, two interfaces per card.
In PC server world such card have been available for while, even 100Gbps cards 
are present.

What about System Z?

--
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, 
https://apac01.safelinks.protection.outlook.com/?url=www.mBank.pldata=02%7C01%7Callan.staller%40HCL.COM%7C87af0fc9b39449fbf9df08d5e664b5c6%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C1%7C636668242607683133sdata=x8ELxytTefZxN9hREDcBJhSTm7Vu%2BkDQ8BOYDILUI04%3Dreserved=0,
 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.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.

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

New OSA cards?

I just read Announcement Letter from IBM, Power machines now have 
network interface cards 40GbE, two interfaces per card.
In PC server world such card have been available for while, even 100Gbps 
cards are present.


What about System Z?

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


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

Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

2018-07-10 Thread ITschak Mugzach

... And I may add that if VSE JCL was so good, it wouldn't have so many
private extensions (and I've seem some of them).

ITschak

On Tue, Jul 10, 2018 at 2:37 PM Dana Mitchell  wrote:

> My memories of VSE JCL are dated, and quite possbily incorrect with
> current VSE, but I recall that I felt it was more complicated that MVS
> jcl.  It had more types of statements (although fewer parms per type),
>  JOB, * $$ JOB,  UPSI, OPTION, LIBDEF,  PAUSE, and EXEC statements.   To
> describe a disk file, potentially required at least 3 statements,  ASSIGN,
> DLBL, and EXTENT.  Tape required ASSIGN and TLBL,  tape, disk and inline
> files were not interchangeable as far as programs were concerned.
>
> An interesting 'feature' was that syntax checking was done at execution
> time, so when a JCL error was encountered, a console message was issued
> that required a reply,  allowing you to retype the errant statement.  So in
> the days of real card readers, if you needed to make a quick one time
> change to a job, you could just flip the card around backwards, causing
> 'Invalid Statement' console message prompt,  allowing you to type in the
> statement you really wanted.
>
> Dana
>
> On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris 
> wrote:
> > How does z/OS JCL compare with VSE JCL?  My memories of DOS360 JCL
> probably are
> >irrelevant.
> >
> >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

Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

2018-07-10 Thread Dana Mitchell

My memories of VSE JCL are dated, and quite possbily incorrect with current 
VSE, but I recall that I felt it was more complicated that MVS jcl.  It had 
more types of statements (although fewer parms per type),   JOB, * $$ JOB,  
UPSI, OPTION, LIBDEF,  PAUSE, and EXEC statements.   To describe a disk file, 
potentially required at least 3 statements,  ASSIGN, DLBL, and EXTENT.  Tape 
required ASSIGN and TLBL,  tape, disk and inline files were not interchangeable 
as far as programs were concerned.  

An interesting 'feature' was that syntax checking was done at execution time, 
so when a JCL error was encountered, a console message was issued that required 
a reply,  allowing you to retype the errant statement.  So in the days of real 
card readers, if you needed to make a quick one time change to a job, you could 
just flip the card around backwards, causing 'Invalid Statement' console 
message prompt,  allowing you to type in the statement you really wanted.

Dana

On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris  wrote:
> How does z/OS JCL compare with VSE JCL?  My memories of DOS360 JCL probably 
> are
>irrelevant.
>
>Clark Morris
>

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

IXC344I send cnt: when does it wrap?

2018-07-10 Thread Vernooij, Kees (ITOPT1) - KLM

IXC344I displays the number of messages sent per transport class and message 
length.
The message manual states that this number may wrap.
The System z Parallel Sysplex Best Practices Redbook from 2011 states that this 
number wraps at 99,999,999.

However I see larger counts. When does this number wrap in z/OS V2.2?

Kees.


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

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


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

Re: Sysplex between two hardware


W dniu 2018-07-10 o 06:56, Timothy Sipples pisze:

I should also respond to this part:

Radoslaw Skorupka wrote:

...for availability reasons one should avoid having CF
and z/OS LPAR on the same hardware, which means

That's not phrased as IBM would phase it, and it's not correct as written.

Even when there's some merit in physically separating the CF, the physical
separation need only be between that CF and the particular z/OS Parallel
Sysplex it serves. Having other z/OS LPARs, even LPARs that are
participating in other Parallel Sysplexes, on the same machine as the CF is
consistent with IBM's recommendations here.

David Raften has published a whitepaper (updated in May, 2018) that
explains the various CF configuration options. The direct link to the
current edition is here:

https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971usen-.pdf

[...]

I quickly browsed the document and found confirmation what I learned 
several years ago.

That means:
Yes, you need either standalone CF (*see note) or CF structure 
duplexing! This is required for *some* structures, but ...it is. David 
Rften call it structures which /require failure independence/.


Note: Standalone CF should be understood here as LOGICAL stand alone CF.
IBM-MIAN do not allo pictures, so I'll try to describe it:
SYSPLEX PROD:
z/OS 1 in CPC A, z/OS 2 in CPC B, and CF2 in CPC B or A. And CF1 in CPC C.
Three CPCs.
However CPC C may be used for other purpose, i.e. for test LPARs. 
Anything but z/OS image belonging to the sysplex PROD.


There is also two-CPC configuration
z/OS 1 + CF1 in CPC A, z/OS 2 + CF2 in CPC B and *some structures are 
duplexed*.
What I heard unofficially from IBM-ers is such configuration is "budget" 
read: when you cannot afford good one.

And the link between CFs should be really local (short).


Note2: it is also possible to build a configuration without dedicated 
(logical stand alone) CF and without duplexing. Your choice.
However it is NOT resistant to all possible (single) failures. Yes, it 
is still better than parallel sysplex with single CF, but still 
vulnerable to some failures.


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



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

Re: REXX as JCL replacement

2018-07-10 Thread Ward Able, Grant

Seymour, I have to interject here and state that I like JCL. There - it is out 
in the open and I feel much better for having said it :-)
I am not going to say that it cannot be improved, of course it can, but I think 
it is a wonderful tool that has grown over the years, while HAVING to maintain 
most backward compatibility so it seems limited in how it can change, because 
of the need to maintain that compatibility.


Regards - Grant



DTCC Internal (Green)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: 09 July 2018 16:10
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement

ATTENTION! This email originated outside of DTCC; exercise caution.


 1. I don't recall anybody on IBM-MAIN claims that JCL is good.

 2. Creative solutions are good if they solve the actual problem, not
just an imaginary or irrelevant one.

 2. Sleep does not address the deadly embrace problem.

 3. PDSE does not solve the problem.


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


From: IBM Mainframe Discussion List  on behalf of 
Hobart Spitz 
Sent: Monday, July 9, 2018 8:46 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement

Ward wrote:
>What are the problems (perceived or real) that will be resolved by
replacing JCL with REXX?

I think that it's important to first understand the characteristics on which 
many people base their thinking that JCL is good and may never go away.  The 
point is important, and the basis is a valid concern.  The conclusion is wrong. 
 All it takes is understanding the problem and coming up with creative 
solutions.  As I describe below, DB2 based applications and those that use only 
PDSEs are likely to be good starting points.

One valuable feature of z/OS batch processing is that all ENQs for the entire 
JOB are obtained before any step execution actually starts.  This is done to 
prevent a deadly embrace:  JOB A has exclusive access to dataset X and needs 
exclusive access to dataset Y.  JOB B has access to Y and needs exclusive on X. 
 Neither JOB can proceed until one is canceled, resulting in lost production.  
Despite this being a useful service, there is no TSO equivalent, either via a 
parallel ENQs (as Seymour suggested) or a standard SLEEP mechanism to allow for 
retries.

Other repliers have answered Ward's question well, I was going to cut some of 
the text out of my draft, but didn't.  I think it is important to understand 
what z/OS batch processing does, and where possible, why, so we don't 
trivialize the effort or miss easy opportunities.  I'll share my best educated 
guesses with respect to the subject at hand.

When a batch JOB becomes eligible for execution these actions, relevant to our 
subject, happen in this order:

   1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
   merged with the submitted JCL.  These are necessary for #2 below.
   2. Substitutions are processed.  This is needed for #3; if DSNs could
   change later, via substitution or IF, the ENQs would be incorrect.
   3. ENQs are obtained on all datasets.
   4. The EXECs for PGMs are processed, in order, one at a time.

So any REXX implementation would have either to forgo do initial ENQs, or 
commit to not changing DSNs during processing, or observe certain conventions.  
These conventions could include the following, one or the other may be 
appropriate depending on the applications' needs:

   - Perform ENQs in a consistent order.  (Left as an exercise for the
   reader.  :-)  )
   - Do all ALLOCations up front, and free all exclusive allocations before
   a second set of ENQs is requested.
   - Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
   or ALLOC failure, and taking appropriate action to recover/restart/suspend
   processing.  Initial ENQs are not required.  If implemented via a common
   routine, either site or vendor provided, this could be more viable.  A
   little additional coding to support automated restart might be needed; see
   also below on my first attempt at using REXX instead of JCL.
   - Something else.

It might be helpful to know if, with all the changes and advancements, 
deadly-embraces are still the issue it was in the 1960s-1980s.  As I explain 
below, an application that does not update any sequential datasets or PDSs, 
does not have this as a major concern.  E.g. an application where all data 
updates are done to DB2 tables and PDSEs.  Replace sequential datasets and PDSs 
with PDSEs, even if there is only one member.

If you allow a dataset name to be set based on something only available during 
execution time, there can be no initial ENQs, since the dataset name is not 
known before the first step starts.

Further, z/OS batch processing in general, and initial ENQs, specifically, lock 
in current customers due to the cost of porting and lack of equivalent features

Re: Sysplex between two hardware

2018-07-10 Thread Martin Packer

Thanks. I wasn't, in that post, intending to talk about Duplexing 
performance. Merely how I know about deactivated LPARs from RMF SMF - in 
case anybody wondered.

(In recent engagements I've used the deactivated LPARs' names and 
locations to drive brief discussions on Availability setup etc.)

It's possible you'll like this one, though I don't think it helps you with 
Performance all that much: 

https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/coupling_facility_duplexing_reporting_warm_over?lang=en

And it's (almost) time I wrote about Async CF Duplexing - which might 
possibly be helpful to you.

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Ravi Gaur 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   10/07/2018 09:35
Subject:Re: Sysplex between two hardware
Sent by:IBM Mainframe Discussion List 



Martin, thanks I time to time read your blogs very useful however one you 
pasted for the deactivated lpar's doesn't have much on the performance 
side ...anyway yes we have LOCK1 duplex...here's an example from our dev 
partitions.

  STRNAME: Dxxx_LOCK1 
   STATUS: REASON SPECIFIED WITH REBUILD START: 
 POLICY-INITIATED 
   DUPLEXING REBUILD 
 METHOD: SYSTEM-MANAGED 
   AUTO VERSION: D290AFB4 34496191 
 PHASE: DUPLEX ESTABLISHED 
   EVENT MANAGEMENT: MESSAGE-BASED 
   TYPE: LOCK 
   POLICY INFORMATION: 
POLICY SIZE: 310 M 
POLICY INITSIZE: 256 M 
POLICY MINSIZE : 256 M 
FULLTHRESHOLD  : 80 
ALLOWAUTOALT   : YES 
REBUILD PERCENT: 1 
DUPLEX : ENABLED 
ALLOWREALLOCATE: YES 
PREFERENCE LIST: CxxECC1  CxxECC1 

--
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: Sysplex between two hardware

2018-07-10 Thread Ravi Gaur

Martin, thanks I time to time read your blogs very useful however one you 
pasted for the deactivated lpar's doesn't have much on the performance side 
...anyway yes we have LOCK1 duplex...here's an example from our dev partitions.

  STRNAME: Dxxx_LOCK1 
   STATUS: REASON SPECIFIED WITH REBUILD START:   
 POLICY-INITIATED 
   DUPLEXING REBUILD  
 METHOD: SYSTEM-MANAGED   
   AUTO VERSION: D290AFB4 34496191
 PHASE: DUPLEX ESTABLISHED
   EVENT MANAGEMENT: MESSAGE-BASED
   TYPE: LOCK 
   POLICY INFORMATION:
POLICY SIZE: 310 M
POLICY INITSIZE: 256 M
POLICY MINSIZE : 256 M
FULLTHRESHOLD  : 80   
ALLOWAUTOALT   : YES  
REBUILD PERCENT: 1
DUPLEX : ENABLED  
ALLOWREALLOCATE: YES  
PREFERENCE LIST: CxxECC1  CxxECC1

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

Re: Sysplex between two hardware

2018-07-10 Thread Martin Packer

A common pattern (and I often see the inactive LPARs in RMF* SMF) but tell me: 
Do you duplex DB2 LOCK1? And how is that working out performancewise?

* I wrote about how to do this in 
https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/lpars_what_s_in_a_name?lang=en
 in 2014.

Cheers, Martin

Sent from my iPad

> On 10 Jul 2018, at 08:58, Ravi Gaur  wrote:
> 
> We took an approach where for each plex we had CF defined on two cec's as 
> that make sense :
> 
> 1. Systems defined in the plex are defined on both CEC ...i.e. Say we have 
> plex of 4 systems (SYS1,SYS2,SYS3,SYS4), each with 2 systems on one CEC1(SYS1 
> & SYS2 Active(Normal running)  the rest 2 in Inactive state on CEC1 (SYS3 & 
> SYS4) , similar definition goes other way which is CEC2(SYS3 & SYS4 
> Active(normal running) & rest 2 in inactive state on CEC2(SYS1 & SYS2)  
> This provide resiliency in terms of whole CEC Going down ...Now both have CF 
> Definition for the Plex on both CEC which provide resiliency for the CF as 
> well with Structures defined in duplex mode ...This we have been running for 
> years and provide us various benefits example say we are applying or doing 
> microcode upgrade or for various other reason require structures to move 
> around ...those all features can be exploited when we have structures defined 
> in the duplex mode with hardware split over two separate physical box
> So simple rule and policy and commonsense work here 
> 
> --
> 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: Sysplex between two hardware

2018-07-10 Thread Ravi Gaur

We took an approach where for each plex we had CF defined on two cec's as that 
make sense :

1. Systems defined in the plex are defined on both CEC ...i.e. Say we have plex 
of 4 systems (SYS1,SYS2,SYS3,SYS4), each with 2 systems on one CEC1(SYS1 & SYS2 
Active(Normal running)  the rest 2 in Inactive state on CEC1 (SYS3 & SYS4) , 
similar definition goes other way which is CEC2(SYS3 & SYS4 Active(normal 
running) & rest 2 in inactive state on CEC2(SYS1 & SYS2)  This provide 
resiliency in terms of whole CEC Going down ...Now both have CF Definition for 
the Plex on both CEC which provide resiliency for the CF as well with 
Structures defined in duplex mode ...This we have been running for years and 
provide us various benefits example say we are applying or doing microcode 
upgrade or for various other reason require structures to move around ...those 
all features can be exploited when we have structures defined in the duplex 
mode with hardware split over two separate physical box
So simple rule and policy and commonsense work here 

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

Re: IEC614I Scratch

2018-07-10 Thread Ravi Gaur

Please check the MPFLSTxx member hopefully it's suppressed as it does in our 
shop.

IEC614I,SUP(YES),RETAIN(NO),AUTO(YES) /*  ADDED 03/15/01 */

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

Re: Sysplex between two hardware

2018-07-10 Thread Peter

Dear All

I am receiving lot of great responses and I should be back on Mondays.

Apologise for not responding.


Peter

On Tue 10 Jul, 2018, 10:24 AM Vernooij, Kees (ITOPT1) - KLM, <
kees.verno...@klm.com> wrote:

> Well, we don't disagree much, except that that in case of a CF failure, we
> decided take the (few seconds) structure recovery delays and not have the
> duplexing overhead.
>
> Kees.
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Jesse 1 Robinson
> > Sent: 09 July, 2018 18:07
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Sysplex between two hardware
> >
> > I stand by my original reply. All you need is an ICF LPAR in each CEC
> > and physical links to connect the CECs, together with full CF structure
> > duplexing. We have run this way for decades. Suffered two (!) CEC
> > failures over the years. After repairing the failed CEC, we resumed
> > normal operation with *no* recovery actions needed because all sensitive
> > structures were duplexed in the non-failing CEC.
> >
> > Our standalone CFs went away with the 9674.
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > 626-543-6132 Office ⇐=== NEW
> > robin...@sce.com
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Vernooij, Kees (ITOPT1) - KLM
> > Sent: Monday, July 09, 2018 8:08 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: Sysplex between two hardware
> >
> > That was my point: you don't miss a thing.
> > You are fully redundant with CFs in each CPC.
> > And since the latest MQ update, all applications are capable of
> > recovering their structures, so recovery is guaranteed in case of a CF
> > failure.
> >
> > Kees.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > > On Behalf Of Allan Staller
> > > Sent: 09 July, 2018 16:33
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Sysplex between two hardware
> > >
> > > That configuration is perfectly valid. You are merely missing some(but
> > > not all)  redundancy and recovery options.
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > > On Behalf Of R.S.
> > > Sent: Monday, July 9, 2018 9:20 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Sysplex between two hardware
> > >
> > > W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze:
> > > > The essence of the matter is to ensure that the selected
> > > > configuration
> > > meets the availability objectives of the business services supported
> > > by the sysplex.  One must consider the service restoration objectives
> > > for the business services in light of the potential failures that can
> > > occur for a potential choice of configuration.  There are many
> > > possibilities and different installations will of course make
> > > different choices based on their own business objectives.  Choices of
> > > standalone CF, or structure duplexing, and the like are really all
> > > talking about different ways of solving the "failure isolation" issue
> > > (wherein we might be concerned about the time to restore the business
> > > service if we simultaneously lose the data in the CF along with the
> > > system that produced that data).  Each choice has its own advantages
> > > and disadvantages; choose the one that's right for you.
> > > > --Mark Brooks
> > > > --z/OS Sysplex Development
> > > >
> > >
> > > However "option c", that means we don't have standalone CF and we do
> > > not duplex CF structures is not proper one, is it?
> > >
> > > Regards
> > > --
> > > Radoslaw Skorupka
> > > Lodz, Poland
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart

Re: Sysplex between two hardware

2018-07-10 Thread Vernooij, Kees (ITOPT1) - KLM

Well, we don't disagree much, except that that in case of a CF failure, we 
decided take the (few seconds) structure recovery delays and not have the 
duplexing overhead.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: 09 July, 2018 18:07
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sysplex between two hardware
> 
> I stand by my original reply. All you need is an ICF LPAR in each CEC
> and physical links to connect the CECs, together with full CF structure
> duplexing. We have run this way for decades. Suffered two (!) CEC
> failures over the years. After repairing the failed CEC, we resumed
> normal operation with *no* recovery actions needed because all sensitive
> structures were duplexed in the non-failing CEC.
> 
> Our standalone CFs went away with the 9674.
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Vernooij, Kees (ITOPT1) - KLM
> Sent: Monday, July 09, 2018 8:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Sysplex between two hardware
> 
> That was my point: you don't miss a thing.
> You are fully redundant with CFs in each CPC.
> And since the latest MQ update, all applications are capable of
> recovering their structures, so recovery is guaranteed in case of a CF
> failure.
> 
> Kees.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Allan Staller
> > Sent: 09 July, 2018 16:33
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Sysplex between two hardware
> >
> > That configuration is perfectly valid. You are merely missing some(but
> > not all)  redundancy and recovery options.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of R.S.
> > Sent: Monday, July 9, 2018 9:20 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Sysplex between two hardware
> >
> > W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze:
> > > The essence of the matter is to ensure that the selected
> > > configuration
> > meets the availability objectives of the business services supported
> > by the sysplex.  One must consider the service restoration objectives
> > for the business services in light of the potential failures that can
> > occur for a potential choice of configuration.  There are many
> > possibilities and different installations will of course make
> > different choices based on their own business objectives.  Choices of
> > standalone CF, or structure duplexing, and the like are really all
> > talking about different ways of solving the "failure isolation" issue
> > (wherein we might be concerned about the time to restore the business
> > service if we simultaneously lose the data in the CF along with the
> > system that produced that data).  Each choice has its own advantages
> > and disadvantages; choose the one that's right for you.
> > > --Mark Brooks
> > > --z/OS Sysplex Development
> > >
> >
> > However "option c", that means we don't have standalone CF and we do
> > not duplex CF structures is not proper one, is it?
> >
> > Regards
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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



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

Re: Netiquette (was:Sysplex between two hardware)

2018-07-10 Thread Peter

I apologise as I was on personal leave and I will be back on Monday.

I honestly appreciate all the replies and query for which I can
collectively chose and research


Thanks again

On Tue 10 Jul, 2018, 10:02 AM Peter Hunkeler,  wrote:

>
> Peter,
> You've been asking for help here. I consider it very impolite that you
> don't answer peoples inquiries for details.
>
>
> --
> Peter Hunkeler
>
>
>
> *Von: * Peter 
> *An: * IBM-MAIN@LISTSERV.UA.EDU
> *Betreff: * Sysplex between two hardware
> *Datum: * 06.07.18, 04:45
>
> Hi
>
> We are looking up for a solution where we need a LPAR to have a hot
> standby
> in other LPAR running in a different machine .
>
> As we are trying to create a sysplex relationship between two LPARS
> running
> in a different machines .
>
> Apology for my ignorance and is it possible ?
>
> Peter
>
> --
> 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

Netiquette (was:Sysplex between two hardware)