Signing off

[Sean Gleann]

This list has been a great source of ideas and information, although I've
never really been a 'contributor' here, but more of a 'lurker'. Whenever
I've seen a thread that I might be able to respond to, someone else gets in
first with a response very similar to the one that I thought of.

So, I hope you won't mind me speaking up now to say that it's time for this
tired old mainframer to toddle off into the sunset... after 50 years of
working with mainframe systems, I feel it's time to hang up my keyboard and
call it a day.

I first started on an ICL 1904 - punched cards, paper tape, core memory,
60MB disks, GEORGE II - but quickly saw the light and moved to another
employer that used a 360/30 roughly 8 years after the series was first
marketed. Since then, aside from a brief entanglement with a Burroughs
B4700, it's been IBM all the way.

I have to say that it's (mostly) been a lot of fun. From one aspect, I've
never really worked a day in my life. Instead, I've been paid a lot of
money to play on other people's expensive toys.

Here's wishing all of you good luck and good fortune for the future. I'll
be thinking about doing some travelling - haven't made it to South America
or Africa yet.

Regards
Sean o'bhaile na Gleann

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

Re: Question for our international friends (mostly)

[Sean Gleann]

(Coming in a bit late on this thread)
As others have said, 'kicks' and Hursley are closely related (or rather,
_were_. It is my understanding that Hursley Grange is now some sort of IBM
museum.)
The local no. 66 bus goes between Romsey and Winchester via Hursley, so -
at least at some point in the past - it was definitely possible to "get
your kicks on route 66"...

Sean


On Mon, 20 Mar 2023 at 02:40, Jeremy Nicoll 
wrote:

> On Mon, 20 Mar 2023, at 02:23, Seymour J Metz wrote:
> > Also Kipling.
>
> Kindling ??(sorry)
>
> > 
>
> > The root is from "bundle" of sticks and small pieces of wood, and by
> > expansion to bundles of other things.
>
> --
> Jeremy Nicoll - my opinions are my own.
>
> --
> 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: An SDSF curiosity...

[Sean Gleann]

Thanks, Rob - it all makes sense now.
I tried to have a look at my type-79 data, only to find there isn't any
being collected. It seems I have to set up RMF monitor II to collect that.
Maybe I'll think about that later.
Migration to z/OS 2.5 is something planned for later this year.

Regards
Sean

On Tue, 21 Feb 2023 at 13:07, Rob Scott  wrote:

> The SDSF "TranAct" column is based entirely on the R791TTOD field returned
> by ERBSMFI (which in turn is based on OUCBTMO).
>
> This 32-bit value contains the number of milliseconds since the "last
> transaction".
>
> The meaning of "last transaction" varies with the workload, so for some
> address spaces in might reflect the initial program execution and could be
> used to estimate its "up-time".
>
> For TSO users, the "last transaction" will be updated each time ENTER is
> pressed and it is entirely possible that other workloads , for example z/OS
> Unix, have methods to inform WLM to update OUCBTMO.
>
> Note that R791TMO can only hold x'', so for systems that have not
> been IPLed for many months this figure is either going to wrap or stay
> static  (I am not sure which happens).
>
> (For what it is worth, when SDSF detects that a job has been active for
> more than x'' milliseconds, then we show zeroes for the TRANACT and
> TRANRES columns)
>
> Note that SDSF "DA" now has the "Start Date" column in z/OS 2.5 to aid
> users trying to work out the up-time of the ASIDs.
>
> Rob Scott
> Rocket Software
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Sean Gleann
> Sent: 21 February 2023 10:01
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: An SDSF curiosity...
>
> EXTERNAL EMAIL
>
>
>
>
>
> This isn't a 'problem' per se, just an observation that someone else may
> be able to shed some light on...
>
> In SDSF, the DA panel presentation can be modified using the 'View' option.
> For my logon id I have brought the column named 'Tran-Act' in to view, and
> then sorted the display so that Tran-Act is in ascending sequence.
>
> An excerpt for a current display is: (hoping this doesn't get
> reformatted...)
>  NP   JOBNAME  StepName ProcStep JobID  Tran-Act   CPU%   CPU-Time
>   BUILD5   *OMVSEX   STC246650:00:00   0.34   0.01
>   BUILD2   STEP1 STC237440:00:14  22.72   9.53
>   OMVS OMVS OMVS 5:35:02   0.211228.64
>   BUILD9   *OMVSEX   STC23888   14:07:22   2.501458.22
>   SSHD6STEP1 STC23925   14:07:22   0.00   3.49
>   IMS14J11 IMS14J11 JMPRGN   JOB23674   34:44:13   0.00   0.44
>   IMS14F11 IMS14F11 IFP  JOB23671   34:44:21   0.00   0.01
>
> At the bottom of this excerpt, there are two tasks associated with an IMS
> region that was started shortly after the system was  IPL'd, nearly 35
> hours ago. In the full display, there are a number of other tasks below
> this that all have Tran-Act times that are roughly the same.
>
> Above the IMS-related tasks, there are two tasks that have been running
> for a bit over 14 hours.
>
> The OMVS task above that has apparently been running for only five and
> half hours or so, and that is the curiosity...
>
> OMVS is started at IPL time, just like the IMS region in the example
> above, and it is never terminated until we shut the system down again. (in
> the shutdown sequence, it is the last thing to be terminated before JES can
> be stopped).
>
> So why isn't OMVS's "Tran-Act" time in the same ball park as the IMS tasks?
>
> Regards
> Sean
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA
> 02451 ■ Main Office Toll Free Number: +1 855.577.4323
> Contact Customer Support:
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
> http://www.rocketsoftware.com/manage-your-email-preferences
> Privacy Policy -
> http://www.rocketsoftware.com/company/legal/privacy-policy
> 
>
> This communication and any attachments may contain confidential
> information of Rocket Software, Inc. All unauthorized use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> notify Rocket Software immediately and destroy all copies of this
> communication. Thank you.
>
> 

An SDSF curiosity...

[Sean Gleann]

This isn't a 'problem' per se, just an observation that someone else may be
able to shed some light on...

In SDSF, the DA panel presentation can be modified using the 'View' option.
For my logon id I have brought the column named 'Tran-Act' in to view, and
then sorted the display so that Tran-Act is in ascending sequence.

An excerpt for a current display is: (hoping this doesn't get
reformatted...)
 NP   JOBNAME  StepName ProcStep JobID  Tran-Act   CPU%   CPU-Time
  BUILD5   *OMVSEX   STC246650:00:00   0.34   0.01
  BUILD2   STEP1 STC237440:00:14  22.72   9.53
  OMVS OMVS OMVS 5:35:02   0.211228.64
  BUILD9   *OMVSEX   STC23888   14:07:22   2.501458.22
  SSHD6STEP1 STC23925   14:07:22   0.00   3.49
  IMS14J11 IMS14J11 JMPRGN   JOB23674   34:44:13   0.00   0.44
  IMS14F11 IMS14F11 IFP  JOB23671   34:44:21   0.00   0.01

At the bottom of this excerpt, there are two tasks associated with an IMS
region that was started shortly after the system was  IPL'd, nearly 35
hours ago. In the full display, there are a number of other tasks below
this that all have Tran-Act times that are roughly the same.

Above the IMS-related tasks, there are two tasks that have been running for
a bit over 14 hours.

The OMVS task above that has apparently been running for only five and half
hours or so, and that is the curiosity...

OMVS is started at IPL time, just like the IMS region in the example above,
and it is never terminated until we shut the system down again. (in the
shutdown sequence, it is the last thing to be terminated before JES can be
stopped).

So why isn't OMVS's "Tran-Act" time in the same ball park as the IMS tasks?

Regards
Sean

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

Re: test

[Sean Gleann]

Thank you, Carmen.
I used to be able to see my posts and replies, but that seems to have
stopped.
I wonder what has changed.

Sean

On Tue, 6 Sept 2022 at 14:42, Carmen Vitullo  wrote:

> I saw both your posts, I too do not get emails for my posts, replies,
> even though I have set my preferences to get emails.
>
> Carmen
>
>
> On 9/6/2022 8:37 AM, Sean Gleann wrote:
> > test
> > Sean
> >
> > --
> > 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

test

[Sean Gleann]

test
Sean

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

Test

[Sean Gleann]

my posts aren't appearing

Sean

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

Network issues at Dallas RDP site?

[Sean Gleann]

(Possible repeat - not sure if my previous response got through...)



We received email from RDP timestamped 03:07UTC:

"Due to required maintenance, the remote development environment is
temporarily unavailable.
We are working as quickly as we can to restore services, please be patient
and we will update you as soon as possible."

Nothing new since then.
Have not been able to do any work on our z/OS systems at all today

Sean

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

Re: Network issues at Dallas RDP site?

[Sean Gleann]

We received email from RDP timestamped 03:07UTC:

"Due to required maintenance, the remote development environment is
temporarily unavailable.
We are working as quickly as we can to restore services, please be patient
and we will update you as soon as possible."

Nothing new since then.
Have not been able to do any work on our z/OS systems at all today

Sean



On Wed, 31 Aug 2022 at 19:18, Farley, Peter x23353 <
031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> The IBM Zxplore systems at the Dallas RDP site are unreachable (the
> Zxplore website says "network issues").
>
> Has anyone heard anything about what those issues may be?
>
> Peter
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Use of zCX

[Sean Gleann]

@Robert Garrett (with a sigh of relief!) 15 minutes for z/CX to come up on
a z/OS under z/VM at Dallas?   Me too. I thought I was doing something
wrong, but couldn't get any useful feedback from IBM/Dallas about the
'problem'.

Sean

On Thu, 21 Apr 2022 at 04:57, kekronbekron <
02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:

> Apologies if this seems rash.
> Certainly don't mean to belittle people's work; many are restricted with
> choices, procedures, etc.
> If it isn't for the cost of being an MF s/w vendor, competent new
> solutions would steal the show.
> Much like most of y'all, I want Z to remain king of the hill.
>
> -KB
>
> --- Original Message ---
> On Thursday, April 21st, 2022 at 9:06 AM, kekronbekron <
> 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
>
>
> > As an observer, I reckon IBM are forced to use OpenShift because they've
> got to get RedHat in there.
> > Also, since everyone knows the word Docker now, the Z "has to have it".
> > Surely the industry is now waking up to the mess that is the Kubernetes
> ecoystem mgmt., service MESS.
> >
> > I do wonder... for those who thought setting up zOSMF RACF was painful,
> what their journey will be for zCX and OpenShift.
> > Just saying, "it's free because zIIP" doesn't make it good.
> > No Ferrari owner should be "compelled" to use a unicycle's wheel just
> because it's free.
> >
> > IMHO, "Me too" solutions are seriously ruining the reputation of the Z
> with the ridiculous CPU, memory, storage requirements.
> > I thought it was ridiculous that RDz wanted a few gigabytes of memory
> for the JVM.
> > Rebadged oldware, with web stack & interface from early 2010s, are now
> coming to compete with Chrome, in their lust for memory and such.
> >
> > - KB
> > --- Original Message ---
> > On Thursday, April 21st, 2022 at 4:22 AM, Tony Harminc t...@harminc.net
> wrote:
> >
> >
> >
> > > On Wed, 20 Apr 2022 at 18:00, Robert Garrett rob...@garrettfamily.us
> wrote:
> > >
> > > [...]
> > >
> > > > It likes a LOT of real memory and it appears that the running
> instance consumes the full amount of real memory allocated to it for the
> duration, making it unavailable to zOS for paging or any other use. Don't
> believe the claim that it can run in as little
> > > > as 2GB. The experimental test instance that I built had 3GB
> allocated to it (the most I could give it on the LPAR I was using) and it
> took a full 15 minutes (yes minutes) by the clock for the address space to
> initialize and reach the point where it was
> > > > functional - on every start up. Admittedly, this was on a zOS image
> that was being hosted under zVM at IBM Dallas, so I'm sure that had some
> impact.
> > >
> > > That smells like three levels of SIE, which to my understanding is
> > > never going to perform reasonably.
> > >
> > > Tony H.
> > >
> > > --
> > > 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: EAV and zHPF documentation, anyone?

[Sean Gleann]

Hi Timothy
Thanks for your response - it highlights two things for us
1. We were woefully ignorant about the history and current 'packaging' of
zHPF - thank you for your explanation
2. I was not specific enough in my original query. You say that zHPF should
work automagically with BSAM, etc. Apologies for my oversight here, but
what we're looking for is information on creating a channel program that
uses TCWs as opposed to CCWs (our software generates its own channel
programs).

Regards
Sean

On Tue, 26 Oct 2021 at 07:31, Timothy Sipples  wrote:

> Sean Gleann wrote:
> >Also detailed documentation for z/HPF is evading all our searches
> >(because it is a chargeable extra, perhaps?)
>
> I have a partial answer, to start
>
> To my knowledge zHPF is no longer a separately chargeable extra, not for
> several years with IBM gear. My recollection is that zHPF became part of
> the base FICON attachment feature starting with the 2016 introduction of
> the IBM DS8880 series equipment. If a SAN switch vendor wants/wanted to
> charge something I couldn't say, but SAN switches are technically
> optional.
>
> Also to my knowledge there was never anything chargeable on the IBM Z
> server side for zHPF. The base z/OS operating system included support as a
> standard feature (maybe with PTFs depending on the release level), and the
> standard FICON Express features included the necessary hardware support
> all the way back to FICON Express2. Server support goes back to the IBM
> z10 models. Maybe a firmware/microcode update was required (likely for
> z10), but all that should be ancient history by now.
>
> Are you thinking of IBM zHyperLink(s) perhaps? zHyperLink is separately
> chargeable in the sense that it uses dedicated zHyperLink features with
> their own ports (on both ends) and separate/additional cables.
>
> You mentioned "files," so I assume you shouldn't have anything in
> particular to do to exploit zHPF. If the volume (EAV in this case) is zHPF
> enabled then DFSMS Basic Access Methods (BSAM, QSAM, BPAM) should
> "automagically" work.
>
> - - - - - - - - - -
> Timothy Sipples
> I.T. Architect Executive
> Digital Asset & Other Industry Solutions
> IBM Z & LinuxONE
> - - - - - - - - - -
> E-Mail: sipp...@sg.ibm.com
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

EAV and zHPF documentation, anyone?

[Sean Gleann]

We are trying to improve our software product by including provision for
files in cylinder-managed space on EAV disks, and with using z/HPF to
access them.

'DFSMSdpf Advanced Services' (SC23-6861) helps somewhat for FTM8/9 labels,
but it does not go far enough, we feel.
Also detailed documentation for z/HPF is evading all our searches (because
it is a chargeable extra, perhaps?)

Can anyone point me at the kind of documentation we are seeking, please?

Regards
Sean

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

Re: ISPF Edit Macro Regular Expression

[Sean Gleann]

David:
"...I still would like to know how to display which codepage I am using"

I can't see that anyone else has said this, so I might be repeating
something...
In PCOMM, start up a session, and you should see a menu bar at the top,
where one of the options is 'Communication'.
Click on that, then 'Configuration', then 'Session Parameters'.
The value given in the 'Host Code-page' drop-down is what you're looking
for, I think.

Regards
Sean



On Sun, 30 May 2021 at 04:15, Charles Mills  wrote:

> That's why we get the big bucks.
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: Saturday, May 29, 2021 6:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ISPF Edit Macro Regular Expression
>
> > I hate EBCDIC issue, it's a multiple code page set issue!. Pop quiz: when
> using REXX on a PC, is ¬ 'AA'X or 'AC'X?  And, yes, you can cheat and use \
> so you don't have to care which code page and which interpreter, but why
> should you have to? And what if you want to download exist REXX code from,
> e.g., z/OS, zVM?
>
> --
> 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: Upgrading PCOMM query

[Sean Gleann]

Thanks, Radoslaw - PCOMM v14.0.1 now running successfully on my desktop
system
Regards
Sean

On Wed, 14 Apr 2021 at 11:12, Radoslaw Skorupka 
wrote:

> Yes, it is OK.
> Most PCOMM upgrades, even minor ones are just full installation packages.
> You can use it for upgrade or just installation from scratch.
> IMHO there is no license enforcement hindrances.
>
> --
> Radoslaw Skorupka
> (looking for new job)
> Lodz, Poland
>
>
>
>
> W dniu 14.04.2021 o 12:07, Sean Gleann pisze:
> > I recently saw mention somewhere of PCOMM version 14, and realised that I
> > am still using version 13 and have been doing so for longer than I can
> > remember.
> > As a result, I've started down the path of upgrading to version 14.
> >
> > The install package available from IBM appears to be
> > "PCOMM-14.0.1-MLS-RefreshPack-x64", but I bit wary of actually using it.
> > The 'RefreshPack' term in the file name implies - to me at least - that
> it
> > is an upgrade to version 14... and I can't find any sign of a 'base'
> > install package.
> >
> > Can anyone say if it is OK to install this package over an existing
> version
> > 13 installation, please?
> >
> > Regards
> > Sean
> >
> > --
> > 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

Upgrading PCOMM query

[Sean Gleann]

I recently saw mention somewhere of PCOMM version 14, and realised that I
am still using version 13 and have been doing so for longer than I can
remember.
As a result, I've started down the path of upgrading to version 14.

The install package available from IBM appears to be
"PCOMM-14.0.1-MLS-RefreshPack-x64", but I bit wary of actually using it.
The 'RefreshPack' term in the file name implies - to me at least - that it
is an upgrade to version 14... and I can't find any sign of a 'base'
install package.

Can anyone say if it is OK to install this package over an existing version
13 installation, please?

Regards
Sean

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

Re: Request for help with removing sequence numbers from PDS members

[Sean Gleann]

The 'parse source . . me .' modification cracked the problem, Andy - many
thanks!
I see now from my very earliest version of the REXX, I had missed out the
the space between the placeholders for the first two tokens
That led me into a can of worms that eventually resulted in me removing the
'. . me .' completely, leaving just 'parse source'.
Which in turn led to a different can of worms, and from there on it was
just downhill all the way.
As I said early on, it had to be one of those 'basic, simple' things...

Regards
Sean


On Tue, 12 Jan 2021 at 13:23, Andy Styles  wrote:

> Actually, I think it does.
>
> The MACRO parameter should have the name of the calling exec - the other
> parms have values as I would expect.
>
> Can you add a trace ir right at the top,  it should show what the parse
> source is returning; you might instead add a say me ..
>
> The parse line should say:
>
> parse source . . me .
>
> Andy
>
> On Tue, 12 Jan 2021, 13:16 Sean Gleann,  wrote:
>
> > Hi Andy
> >
> > The ISPLOG output doesn't give anything useful, unfortunately.
> >
> > Time*** ISPF transaction log ***
> >
> >
> > 07:08   Start of ISPF Log - - -  - Session # 1
> > 
> > 07:08  TSO - Command  -  - STRIPNOS 
> >
> > 07:08   * Dialog Error * - Application(ISP); Function Command
> > (STRIPNOS); Service(EDIT)
> > 07:08  Line from cmd:- EDIT DATAID(ISR1) MEMBER(TEST1)
> > MACRO()  <<'TEST1' is the name of the first
> > member in the incoming PDS, though.
> > 07:08  BDISPMAX exceeded - 100 displays exceeded in batch mode on
> > panel
> >
> > Regards
> > Sean
> >
> > On Tue, 12 Jan 2021 at 12:56, Sri h Kolusu  wrote:
> >
> > > Sean,
> > >
> > > If your shop has File-manager , the following JCL will give you the
> > desired
> > > results
> > >
> > > //STEP0100 EXEC PGM=FILEMGR
> > > //SYSPRINT DD SYSOUT=*
> > > //PDS  DD DISP=SHR,DSN=Your.PDS/PDSE.to.remove.seqnum
> > > //SYSINDD *
> > > $$FILEM FCH INPUT=PDS
> > > C  P'=' ' ' 73 80
> > > /*
> > >
> > >
> > > Thanks,
> > > Kolusu
> > >
> > > --
> > > 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: Request for help with removing sequence numbers from PDS members

[Sean Gleann]

Hi Andy

The ISPLOG output doesn't give anything useful, unfortunately.

Time*** ISPF transaction log ***


07:08   Start of ISPF Log - - -  - Session # 1

07:08  TSO - Command  -  - STRIPNOS 

07:08   * Dialog Error * - Application(ISP); Function Command
(STRIPNOS); Service(EDIT)
07:08  Line from cmd:- EDIT DATAID(ISR1) MEMBER(TEST1)
MACRO()  <<'TEST1' is the name of the first
member in the incoming PDS, though.
07:08  BDISPMAX exceeded - 100 displays exceeded in batch mode on
panel

Regards
Sean

On Tue, 12 Jan 2021 at 12:56, Sri h Kolusu  wrote:

> Sean,
>
> If your shop has File-manager , the following JCL will give you the desired
> results
>
> //STEP0100 EXEC PGM=FILEMGR
> //SYSPRINT DD SYSOUT=*
> //PDS  DD DISP=SHR,DSN=Your.PDS/PDSE.to.remove.seqnum
> //SYSINDD *
> $$FILEM FCH INPUT=PDS
> C  P'=' ' ' 73 80
> /*
>
>
> Thanks,
> Kolusu
>
> --
> 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: Request for help with removing sequence numbers from PDS members

[Sean Gleann]

Hi Andy

"is it just that you're seeing the RC20 from the ISREDIT" - in this
particular version of the REXX it is, but as previously detailed I had
problems with the syntax of the CONTROL ERRORS statement.
"Does the REXX continue afterwards if you uncomment the code" - in a manner
of speaking, yes. The whole job terminates with RC990.
Here's the SYSTSPRT produced by running the uncommented REXX, with 'trace
i' specified:

 3 *-* parse source

 4 *-* arg dataset

   >>>   "**"

 5 *-* say "PDS to be modified:" dataset

   >L>   "PDS to be modified:"

   >V>   "**"

   >O>   "PDS to be modified: **"

PDS to be modified: **

 6 *-* "ISPEXEC CONTROL ERRORS RETURN"

   >L>   "ISPEXEC CONTROL ERRORS RETURN"

 7 *-* "ISREDIT MACRO"

   >L>   "ISREDIT MACRO"

   +++ RC(20) +++

 8 *-* edMac = rc

   >V>   "20"

 9 *-* "ISPEXEC CONTROL ERRORS CANCEL"

   >L>   "ISPEXEC CONTROL ERRORS CANCEL"

10 *-* if edMac = 0

   >V>   "20"

   >L>   "0"

   >O>   "0"

14 *-* "ISPEXEC LMINIT DATAID(DSN) DATASET('"dataset"') ENQ(SHR)"

   >L>   "ISPEXEC LMINIT DATAID(DSN) DATASET('"

   >V>   "**"

   >O>   "ISPEXEC LMINIT DATAID(DSN) DATASET('**"

   >L>   "') ENQ(SHR)"

   >O>   "ISPEXEC LMINIT DATAID(DSN) DATASET('**')
ENQ(SHR)"
15 *-* "ISPEXEC LMOPEN DATAID()"

   >L>   "ISPEXEC LMOPEN DATAID()"

16 *-* Do until RC > 0

17 *-*  "ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMBER)
STATS(NO)"
   >L>"ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMBER)
STATS(NO)"
18 *-*  If RC = 8

   >V>"0"

   >L>"8"

   >O>"0"

20 *-*  If RC = 0

   >V>"0"

   >L>"0"

   >O>"1"

   *-*   Then

21 *-*   "ISPEXEC EDIT DATAID() MEMBER() MACRO()"

   >L> "ISPEXEC EDIT DATAID() MEMBER() MACRO()"

  ISPP330 BDISPMAX exceeded   -/-100 displays exceeded in batch mode on
panel

Regards
Sean

On Tue, 12 Jan 2021 at 11:06, Andy Styles  wrote:

> Twice recently I've tried to paste an answer to a question involving some
> REXX output and been caught by our DLP filters.
>
> Subscribing separately to avoid that!
>
> Anyway, is it just that you're seeing the RC20 from the ISREDIT?
>
> I would expect that on the first invocation, the CONTROL ERRORS  wrapper
> is there to stop ISPF terminating the exec with a severe error.
>
> Does the REXX continue afterwards if you uncomment the code?
>
> Andy
>
> --
> 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: Request for help with removing sequence numbers from PDS members

[Sean Gleann]

I've been told by Powers That Be that this line of development is redundant
& that a different solution has been independently developed elsewhere in
the company. (*sigh* - 'twas ever thus)
But I'm still interested in discovering what I'm doing wrong.
To that end, here's the jobstream I'm using, in the hope that someone can
pin-point the problem:
(I do so hope that this comes through without being reformatted by various
e-mail servers...)


//RUNREXX  EXEC PGM=IKJEFT01
//SYSTSPRT DD   SYSOUT=*
//ISPMLIB  DD   DSN=ISP.SISPMENU,DISP=SHR
//ISPPLIB  DD   DSN=ISP.SISPPENU,DISP=SHR
//ISPSLIB  DD   DSN=ISP.SISPSLIB,DISP=SHR
//ISPTLIB  DD   DSN=ISP.SISPTENU,DISP=SHR
//ISPPROF  DD   DISP=(NEW,PASS),SPACE=(TRK,(1,1,1)),
//  DSORG=PO,RECFM=FB,BLKSIZE=27920,LRECL=80
//SYSEXEC  DD   DSN=,DISP=SHR
//SYSTSIN  DD   *
ISPSTART CMD(STRIPNOS )

and here is the first part of the STRIPNOS REXX program - such as it is
right now:

/* REXX to strip line numbers in place */
/* trace i */
parse source
arg dataset
say "PDS to be modified:" dataset
"ISPEXEC CONTROL ERRORS RETURN"
"ISREDIT MACRO"
edMac = rc
"ISPEXEC CONTROL ERRORS CANCEL"
 (followed by the rest of Andy's solution, currently all commented out)


 ** Mark well that phrase 'as it is right now'. As I've already detailed,
I've tried many different variants of this code to try and get something
working, with a notable lack of success

Regards
Sean

On Mon, 11 Jan 2021 at 20:03, Lennie Dymoke-Bradshaw <
032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote:

> Apologies, you wanted to do a PDS member.
>
> //EDIT EXEC  PGM=IKJEFT01
> //SYSTSPRT  DD   SYSOUT=*
> //SYSTSIN   DD   *
>EDIT 'LEN.X.TEST.NVSAM.PDS(#ASM)' DATA
>LIST
>UNNUM
>LIST
>END SAVE
> /*
> //
>
> Note the LIST commands are optional.
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Lennie Dymoke-Bradshaw
> Sent: 11 January 2021 19:48
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Request for help with removing sequence numbers from PDS
> members
>
> Here's how to do it using TSO EDIT.
>
> //EDIT EXEC  PGM=IKJEFT01
> //SYSTSPRT  DD   SYSOUT=*
> //SYSTSIN   DD   *
>EDIT 'LEN.X.TEST.NVSAM.FB80' DATA
>LIST
>UNNUM
>LIST
>END SAVE
> /*
> //
>
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Lennie Bradshaw
> Sent: 11 January 2021 12:26
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Request for help with removing sequence numbers from PDS
> members
>
> How about TSO EDIT (yes TSO, not ISPF) in batch.
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of R.S.
> Sent: 11 January 2021 10:21
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Request for help with removing sequence numbers from PDS
> members
>
> W dniu 11.01.2021 o 10:05, Sean Gleann pisze:
> > This has almost certainly cropped up before but try as I might, I
> > can't spot anything obvious in the archives.
> >
> > I have a need to strip sequence numbers from members in a PDS or PDSE.
> > The input PDS(E) has DCB characteristics of REFCM=FB,LRECL-80, and
> > contains an unknown number of members. Of those members, some will
> > have records with 'old data' in character positions 73-80 (that is -
> > sequence numbers, or whatever remains of them).
> > I want to be able to copy this input PDS(E) to a new one with the same
> > DCB info, but all records in all members must have spaces in positions
> 73-80.
> >
> > I thought that ICETOOL might be able to do this but as far as I can
> > see, ICETOOL needs to be told which member names to process. That
> > information is readily available while developing and testing a
> > solution, but not when the result is used in a more general scenario.
> >
> > Can anyone point me at some sort of solution that I might adapt, please?
> > Perhaps there is something on the CBT tape that might help...
>
> I don't know any tool, but I have some idea how to do it.
> Use REXX script.
> It's quite simple to get member list and do somethin in a loop until last
> member is processed.
> What to do?
> Again, I don't know any tool, however it could be feasible to use IEBGENER
> with non-empty SYSIN, ICEMAN, or TSO EDIT, or ISPF EDIT, or something else.
> Caution: things are simple when you just want to replace position 73-80
> despite of its actual content, that means without checking it.
>
> HTH
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wia

Re: Request for help with removing sequence numbers from PDS members

[Sean Gleann]

Jeremy - I tried variants of what you suggest, but all to no avail.

"ISPEXEC CONTROL ERRORS RETURN" appears to be OK - at least, there's no
error message.

"ADDRESS ISPEXEC CONTROL ERRORS RETURN" results in
IKJ56500I COMMAND ADDRESS NOT FOUND
   +++ RC(-3) +++

Splitting the command into two gives
"ADDRESS ISPEXEC"
IKJ56500I COMMAND ADDRESS NOT FOUND
   +++ RC(-3) +++
"CONTROL ERRORS RETURN"
IKJ56500I COMMAND CONTROL NOT FOUND
   +++ RC(-3) +++

So I'm at a bit of a loss, really.
RC(-3) is an environment problem, no?

I'm trying to run the REXX in in a batch job with IKJEFT01.
I've got DD statements for ISP[M,P,S,T,]LIB pointing at relevant datasets
and a (now corrected) DD for ISPPROF, referring to a temporary file.
A SYSEXEC DD points to the PDS containing my REXX program.
For the SYSTSIN, I've got ISPSTART CMD()

The next command in the REXX is "ISREDIT MACRO", but that leads back to the
RC(20) situation
"ISPEXEC CONTROL ERRORS RETURN"
"ISREDIT MACRO"
  +++ RC(20) +++

Regards
Sean

On Mon, 11 Jan 2021 at 16:18, Lars Höglund  wrote:

> Example of ISPF-proc
>
> //*  PROC ISPFBAT
> //ISPFBAT  PROC
> //*
> //*--
> //* STEPNAME: CREPROF
> //* STEPINFO: CREATE ISPPROF
> //*--
> //CREPROF  EXEC PGM=IEFBR14
> //ISPTLIB  DD DISP=(NEW,PASS),
> //SPACE=(TRK,(15,15,5)),
> //LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
> //DSN=&
> //ISPTABL  DD DISP=(NEW,PASS),
> //SPACE=(TRK,(15,15,5)),
> //LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
> //DSN=&
> //*
> //*--
> //* STEPNAME: BATCHPDF
> //* STEPINFO: EXECUTE ISPF IN BATCH
> //*--
> //BATCHPDF EXEC PGM=IKJEFT01,DYNAMNBR=128,
> // PARM='ISPSTART CMD( )'
> //SYSEXEC  DD  DISP=SHR,DSN=YOUR.ISPEXEC<---
> // DD  DISP=SHR,DSN=ISP.SISPEXEC
> //SYSPROC  DD  DISP=SHR,DSN=ISP.SISPCLIB
> //ISPPLIB  DD  DISP=SHR,DSN=ISP.SISPPENU
> //ISPSLIB  DD  DISP=SHR,DSN=YUOR.ISPSLIB<---
> // DD  DISP=SHR,DSN=ISP.SISPSLIB
> // DD  DISP=SHR,DSN=ISP.SISPSENU
> //ISPMLIB  DD  DISP=SHR,DSN=YOUR.ISPMLIB<---
> // DD  DISP=SHR,DSN=ISP.SISPMENU
> // DD  DISP=SHR,DSN=ISF.SISFMLIB
> // DD  DISP=SHR,DSN=SYSU.XMITIP.MSGS
> //ISPLLIB  DD  DUMMY
> //ISPPROF  DD  UNIT=WORK,SPACE=(TRK,(9,1,4)),
> // LRECL=80,BLKSIZE=3120,RECFM=FB,DSORG=PO
> //ISPTABL  DD  DISP=(OLD,DELETE),DSN=&
>
> Use of proc
>
> //S010 EXEC ISPFBAT,
> // ISPFREX=ACCTCHGN,
> // ISPFPRM=''
> //BATCHPDF.SYSTSIN  DD  DUMMY
>
>
> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List  För Paul
> Gilmartin
> Skickat: den 11 januari 2021 17:07
> Till: IBM-MAIN@LISTSERV.UA.EDU
> Ämne: Re: Request for help with removing sequence numbers from PDS members
>
> On Mon, 11 Jan 2021 15:37:55 +, Sean Gleann wrote:
>
> >Many thanks to all who responded.
> >I opted to adapt and (try to) use the REXX that Andy Styles gave, but
> >I'm tripping up over something that has to be one of those 'simple, basic'
> >things.
> >The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
> >I think I've got to use an 'ADDRESS ISPEXEC' command or something like
> >that at the start of the REXX, but attempts at variants of this give
> >the same result.
> >
> You need to run your Rexx under ISPF, which implies you need to run under
> TSO.
> This can all be done in batch, with suitably complex DD statements.
>
> Otherwise, RC(20)
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Request for help with removing sequence numbers from PDS members

[Sean Gleann]

Please ignore my last...
yep - it was one of those 'simple basic' things.
I had a DD statement to define a temporary ISPPROF, where I'd coded
'DSORG=PS' instead of 'PO'.
(seems strange that you can code 'SPACE=(TRK,(1,1,1))' along with
'DSORG=PS' without getting at least a warning...)
Regards
Sean

On Mon, 11 Jan 2021 at 15:37, Sean Gleann  wrote:

> Many thanks to all who responded.
> I opted to adapt and (try to) use the REXX that Andy Styles gave, but I'm
> tripping up over something that has to be one of those 'simple, basic'
> things.
> The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
> I think I've got to use an 'ADDRESS ISPEXEC' command or something like
> that at the start of the REXX, but attempts at variants of this give the
> same result.
> Any clues, anyone... please?
>
> Regards
> Sean
>
>
> On Mon, 11 Jan 2021 at 12:26, Lennie Bradshaw <
> 032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote:
>
>> How about TSO EDIT (yes TSO, not ISPF) in batch.
>> Lennie
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf
>> Of R.S.
>> Sent: 11 January 2021 10:21
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Request for help with removing sequence numbers from PDS
>> members
>>
>> W dniu 11.01.2021 o 10:05, Sean Gleann pisze:
>> > This has almost certainly cropped up before but try as I might, I can't
>> > spot anything obvious in the archives.
>> >
>> > I have a need to strip sequence numbers from members in a PDS or PDSE.
>> > The input PDS(E) has DCB characteristics of REFCM=FB,LRECL-80, and
>> contains
>> > an unknown number of members. Of those members, some will have records
>> with
>> > 'old data' in character positions 73-80 (that is - sequence numbers, or
>> > whatever remains of them).
>> > I want to be able to copy this input PDS(E) to a new one with the same
>> DCB
>> > info, but all records in all members must have spaces in positions
>> 73-80.
>> >
>> > I thought that ICETOOL might be able to do this but as far as I can see,
>> > ICETOOL needs to be told which member names to process. That
>> information is
>> > readily available while developing and testing a solution, but not when
>> the
>> > result is used in a more general scenario.
>> >
>> > Can anyone point me at some sort of solution that I might adapt, please?
>> > Perhaps there is something on the CBT tape that might help...
>>
>> I don't know any tool, but I have some idea how to do it.
>> Use REXX script.
>> It's quite simple to get member list and do somethin in a loop until
>> last member is processed.
>> What to do?
>> Again, I don't know any tool, however it could be feasible to use
>> IEBGENER with non-empty SYSIN, ICEMAN, or TSO EDIT, or ISPF EDIT, or
>> something else.
>> Caution: things are simple when you just want to replace position 73-80
>> despite of its actual content, that means without checking it.
>>
>> HTH
>>
>> --
>> Radoslaw Skorupka
>> Lodz, Poland
>>
>>
>>
>>
>>
>> ==
>>
>> Jeśli nie jesteś adresatem tej wiadomości:
>>
>> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
>> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
>> zapisałeś na dysku).
>> Wiadomość ta może zawierać chronione prawem informacje, które może
>> wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia
>> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
>> narusza prawo i może podlegać karze.
>>
>> mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,
>> www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
>> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
>> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
>> 01.01.2020 r. wynosi 169.401.468 złotych.
>>
>> Jesteśmy administratorem twoich danych osobowych, które podałeś w związku
>> z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które
>> wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną
>> działalnością bankową.
>> Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe
>> znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na
>> www.mbank.pl/rodo
>>
>>
>> If you are not the addressee of this message:
>>
>> - let us know by r

Re: Request for help with removing sequence numbers from PDS members

[Sean Gleann]

Many thanks to all who responded.
I opted to adapt and (try to) use the REXX that Andy Styles gave, but I'm
tripping up over something that has to be one of those 'simple, basic'
things.
The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
I think I've got to use an 'ADDRESS ISPEXEC' command or something like that
at the start of the REXX, but attempts at variants of this give the same
result.
Any clues, anyone... please?

Regards
Sean


On Mon, 11 Jan 2021 at 12:26, Lennie Bradshaw <
032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote:

> How about TSO EDIT (yes TSO, not ISPF) in batch.
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of R.S.
> Sent: 11 January 2021 10:21
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Request for help with removing sequence numbers from PDS
> members
>
> W dniu 11.01.2021 o 10:05, Sean Gleann pisze:
> > This has almost certainly cropped up before but try as I might, I can't
> > spot anything obvious in the archives.
> >
> > I have a need to strip sequence numbers from members in a PDS or PDSE.
> > The input PDS(E) has DCB characteristics of REFCM=FB,LRECL-80, and
> contains
> > an unknown number of members. Of those members, some will have records
> with
> > 'old data' in character positions 73-80 (that is - sequence numbers, or
> > whatever remains of them).
> > I want to be able to copy this input PDS(E) to a new one with the same
> DCB
> > info, but all records in all members must have spaces in positions 73-80.
> >
> > I thought that ICETOOL might be able to do this but as far as I can see,
> > ICETOOL needs to be told which member names to process. That information
> is
> > readily available while developing and testing a solution, but not when
> the
> > result is used in a more general scenario.
> >
> > Can anyone point me at some sort of solution that I might adapt, please?
> > Perhaps there is something on the CBT tape that might help...
>
> I don't know any tool, but I have some idea how to do it.
> Use REXX script.
> It's quite simple to get member list and do somethin in a loop until
> last member is processed.
> What to do?
> Again, I don't know any tool, however it could be feasible to use
> IEBGENER with non-empty SYSIN, ICEMAN, or TSO EDIT, or ISPF EDIT, or
> something else.
> Caution: things are simple when you just want to replace position 73-80
> despite of its actual content, that means without checking it.
>
> HTH
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> Jesteśmy administratorem twoich danych osobowych, które podałeś w związku
> z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które
> wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną
> działalnością bankową.
> Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe
> znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na
> www.mbank.pl/rodo
>
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.401.468 as at 1 January 2020.

Request for help with removing sequence numbers from PDS members

[Sean Gleann]

This has almost certainly cropped up before but try as I might, I can't
spot anything obvious in the archives.

I have a need to strip sequence numbers from members in a PDS or PDSE.
The input PDS(E) has DCB characteristics of REFCM=FB,LRECL-80, and contains
an unknown number of members. Of those members, some will have records with
'old data' in character positions 73-80 (that is - sequence numbers, or
whatever remains of them).
I want to be able to copy this input PDS(E) to a new one with the same DCB
info, but all records in all members must have spaces in positions 73-80.

I thought that ICETOOL might be able to do this but as far as I can see,
ICETOOL needs to be told which member names to process. That information is
readily available while developing and testing a solution, but not when the
result is used in a more general scenario.

Can anyone point me at some sort of solution that I might adapt, please?
Perhaps there is something on the CBT tape that might help...

Regards
Sean

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

Re: DFDSS support for ZFS files query

[Sean Gleann]

Thank you, Ernesto - much appreciated
Vote added.

Regards
Sean


On Wed, 30 Sep 2020 at 15:55, Ernesto Figueroa  wrote:

> You are correct. For now, you must specify all the path names, but we
> understand this is a capability that ought to be provided in DFSMSdss.  As
> others have mentioned, you may be able to use other tools to craft a list
> of path names and use that to generate DFSMSdss SYSIN statements.  There is
> an existing RFE to provide the capability to dump an entire directory
> including all the files and sub-directories, if you feel this is an
> important feature to be included in the product please cast your vote here:
> http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=140801
>
> Ernesto E. Figueroa
> DFSMSdss Development Lead
> erfig...@us.ibm.com
> IBM SystemsGroup
>
> --
> 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: DFDSS support for ZFS files query

[Sean Gleann]

I'm hoping that it's still a 'work in progress' & that one day I'll be able
to say 'DUMP PATH INCLUDE('/foldera/folderb/**') or something close to that.

Sean

On Wed, 30 Sep 2020 at 11:35, Andrew Rowley 
wrote:

> On 30/09/2020 6:03 pm, Seymour J Metz wrote:
> > The DSS manual say that when you specify a directory, it does not dump
> the files under that directory. That's very different from the behavior of,
> e.g., tar.
>
> I guess I shouldn't be surprised, given how often IBM don't do things
> the way I hoped.
>
> It does seem to be less useful than it could have been. I wonder what
> the thinking was when it was being designed?
>
> Andrew Rowley
>
> --
> 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: DFDSS support for ZFS files query

[Sean Gleann]

Wayne: Yes, it does look like each file or path has to be explicitly defined

Paul:
'...akin to asking DFMSMdss to select individual PDS members' is an analogy
I had not seen. Thank you. And of course, DFSMSdss has never been able to
do this and it's unlikely it ever will;
'...filenames containing NL...' Again, something I had not considered. I
can confidently say that in the situation that is driving my investigation
that does not happen _now_, but that's no guarantee it won't occur in the
future;
'...use 'pax'...' That's what we do now and it is precisely the thing I'm
trying to move away from. We have data files for a specific system that
consist of a 'z/OS files component' and a 'USS files component'. Both are
dumped in separate independent jobs, and we see a danger that the two
resulting 'dump' files could conceivably get out of synchronisation.

It looks like what I want is not possible at present and is unlikely to be
so in the future.

Thanks for your responses, Gentlemen. I'm going to abandon this particular
investigation for now.

On Tue, 29 Sep 2020 at 16:19, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 29 Sep 2020 08:52:38 +0100, Sean Gleann  wrote:
>
> >I'm currently investigating the use of DFDSS DUMP PATH to secure data held
> >in UNIX files and folders.
> >...
> >"DFSMSdss does not provide wildcard support when processing UNIX files."
> >...
> >I can see a possible method of including a massaged version of 'ls' output
> >in the INCLUDE parameter, but I don't see this as a particularly workable
> >solution.
> >
> The better utility for that is "find" rather than "ls".  "find" supports
> wildcards
> and boolean expressions; "ls" supports neither.  The massaging would need
> to protect special characters with a scheme supported by DFSMSdss.
> Filenames containing NL are a particular challenge.
>
> ALas, z/OS's "find" does not support the precious "-print0" extension.
>
> What you're asking is akin to asking DFSMSdss to select individual PDS
> members.
>
> >Also, with a DUMP of data comes the requirement to be able to RESTORE it
> to
> >- possibly - a different WORKINGDIRECTORY, but I haven't got that far yet.
> >
> Use 'pax".  Mr. Natural sez, Use the right tool for the job.
>
> -- 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

DFDSS support for ZFS files query

[Sean Gleann]

I'm currently investigating the use of DFDSS DUMP PATH to secure data held
in UNIX files and folders.

As far as I can see, I have to specify the WORKINGDIRECTORY to establish
the starting point for the DUMP operation, then use INCLUDE to _explicitly_
specify the files I want. The available documentation states:
"DFSMSdss does not provide wildcard support when processing UNIX files."
which, for my purposes, is a complete show-stopper.

The subject UNIX folder contain many hundreds, perhaps thousands, of
individual files and sub-folders (and sub-sub-folders, etc). What I want to
do is to dump the complete contents of a UNIX folder in a way analogous to
dumping all z/OS files with a common set of HLQs.

I can see a possible method of including a massaged version of 'ls' output
in the INCLUDE parameter, but I don't see this as a particularly workable
solution.

Am I reading things wrongly and missing a vital point here? Does anyone
know if wildcard support is something that will be made available in the
future?

Also, with a DUMP of data comes the requirement to be able to RESTORE it to
- possibly - a different WORKINGDIRECTORY, but I haven't got that far yet.

Regards
Sean

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

Re: ZCX task monitoring, anyone?

[Sean Gleann]

Yuksel
Thank you for that information and I'm sorry I haven't responded sooner
(other work took precedence, as is so often the case).

Your modification to the 'run' command has worked exactly as required. I
now have cadvisor running on my zcx system and overall CPU utilisation is
down to a much more reasonable 5-6% - a very welcome change!

Thanks you again

Regards
Sean




On Wed, 2 Sep 2020 at 22:09, Yuksel Gunal  wrote:

> Hi Sean,
>
> cAdvisor polls for metrics once a second by default.  Though I have not
> seen such high CPU utilization with the default setting, it is worth to run
> cAdvisor with a different setting, one that you can define explicitly when
> you start cAdvisor.  I'd recommend that you try a 10s or 15s interval and
> see if either helps.  To do that, you need to specify the
> "--housekeeping_interval" parameter.  Here is how you'd do it on zCX (sets
> it to 10 seconds):
>
> docker run -v /:/rootfs:ro -v /var/run:/var/run:ro -v /sys:/sys:ro -v
> /var/lib/docker/:/var/lib/docker:ro -v /dev/disk/:/dev/disk:ro -p 8080:8080
> -d --network monitoring --name=cadvisor ibmcom/cadvisor-s390x:0.33.0
> cadvisor --housekeeping_interval=10s
>
> Note that I modified the instructions by adding "cadvisor
> --housekeeping_interval=10s"
>
> Also, Prometheus polls cAdvisor, but cAdvisor's data collection is not
> triggered by Prometheus polling.  It has its own polling cycle and it keeps
> the metrics in memory.  When Prometheus polls cAdvisor, it returns the last
> set of collected metrics from memory.
>
> Yuksel Gunal
>
>

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

Re: ZCX task monitoring, anyone?

[Sean Gleann]

OK, so the scrape_interval part of your answer is something I can quickly
understand and deal with.
I'll put that to one side for now because my interest is with Cadvisor and
how to control it.

To take the parallel example for Prometheus from the IBM red book, I have
to:
 1. create a 'prometheus.yml' file
 2. create a Dockerfile, which features a COPY command referring to that
'prometheus.yml' file
 3. do a 'docker build' of the Prometheus image
 4. then I can 'run' the image.
With subsequent 'runs' of Prometheus I can skip steps 1-3 as they have
already been done.
For Cadvisor, there is no 'build' to be done, thus no copying of a yml file
The only command I know of for Cadvisor is the 'run' command I detailed
earlier in this thread.
(If the Cadvisor image does not exist, then it is automatically downloaded
before being started.)
In conceptual terms, am I right in thinking that I'm downloading a
'program' that has already been prepared for execution?
If that is true, then the value of any control parameters appears to be
hard-coded within the program.
Given this, I'm not sure I have any control over the container manifest for
Cadvisor.

Regards
Sean

On Thu, 27 Aug 2020 at 10:15, Attila Fogarasi  wrote:

> Housekeeping interval is part of the container manifest as it governs
> normal operation, not just performance metric collection.  As such it is
> specified wherever you have your container manifest defined (for example, a
> .yaml file or by HTTP endpoint or HTTP server).   You can also use the
> command line "kubelet" tool.
> Scrape_interval is the value for how often Prometheus asks cAdvisor for
> data from the collection cache, thus it affects cpu used by cAdvisor to
> prepare and send this data to Prometheus.
> As for how Docker monitoring works, you are right that there is overlap in
> the open-source tools, but the hierarchy is cAdvisor collects the metrics
> and also does some aggregation and processing.  You can use just cAdvisor.
> Prometheus is a layer on top, getting metrics from cAdvisor and then
> provides both better quality reporting and also alerting (which cAdvisor
> does not).  The next layer is Grafana which is a generalized metric
> analytics and visualization tool (not just for Docker).  For larger scale
> more complex container environments you need all 3.
> In a z/OS context these 3 tools became integrated circa 30 years ago, but
> for Unix they are not.   Splitting the processing like this has both good
> and bad points (for example Grafana can run in a separate Docker container)
> but definitely burns more cpu (a lot more).   If not careful the
> measurement tooling can cost more than the application being measured, even
> though it is "free".
>
> On Thu, Aug 27, 2020 at 6:02 PM Sean Gleann  wrote:
>
> > Hi Attila - thanks for the pointers, but I'm not sure of how to act upon
> > them.
> >
> > The start-up for Cadvisor that I'm using doesn't feature any pointer to a
> > parameter list, and despite much googling I don't see any mention of
> such a
> > thing. Everything keeps referring back to Prometheus and then on to
> Grafana
> > My Cadvisor start-up (taken directly from the IBM Red Book and slightly
> > modified to comply with local restrictions):
> > docker network create monitoring
> > docker run --name cadvisor -v /sys:/sys:ro -v
> > /var/lib/docker/:/var/lib/docker:ro -v /dev/disk:/dev/disk:ro -d
> --network
> > monitoring ibmcom/cadvisor-s390x:0.33.0
> >
> > Perhaps I'm looking at things the wrong way, but my current understanding
> > is:
> > Cadvisor (and also Nodeexporter) collect various usage stats;
> > Prometheus then gathers that data and does some sort of pre-processing of
> > it (it doesn't tell Cadvisor to 'do something' - it just passively makes
> > use of the data that Cadvisor collects)
> > Grafana takes the data from Prometheus and uses it to generate various
> > graphs/tables/reports.
> >
> > My situation is that when I run Cadvisor on it's own - no other
> containers
> > at all - then it floods as many processors as I define in the zcx
> > start.json file.
> >
> > Whilst Cadvisor is running, I can go to the relevant web-page and I can
> see
> > that it is producing meters/charts, etc all on its own. Since that is the
> > case, what is the point of Grafana?
> >
> > I have a Prometheus.yml file that features the term 'scrape_interval'
> (but
> > not 'housekeeping'), but that file is for use by Prometheus, isn't it?
> How
> > does it affect the amount of work that Cadvisor is doing, since I haven't
> > even started that container yet?
> >
> > Regards
> > Sean
> >
> > On Wed, 26 Aug 2020 at 23:05, Attila Fogarasi 
&g

Re: ZCX task monitoring, anyone?

[Sean Gleann]

*sigh*. Oh, how I wish that various e-mail clients would quit re-formatting
stuff. My previous response here was so nice & neat & tidy before I hit
'Send'. Reading that response back via IBMMain makes me look like a
complete illiterate...

Sean

On Thu, 27 Aug 2020 at 09:01, Sean Gleann  wrote:

> Hi Attila - thanks for the pointers, but I'm not sure of how to act upon
> them.
>
> The start-up for Cadvisor that I'm using doesn't feature any pointer to a
> parameter list, and despite much googling I don't see any mention of such a
> thing. Everything keeps referring back to Prometheus and then on to Grafana
> My Cadvisor start-up (taken directly from the IBM Red Book and slightly
> modified to comply with local restrictions):
> docker network create monitoring
> docker run --name cadvisor -v /sys:/sys:ro -v
> /var/lib/docker/:/var/lib/docker:ro -v /dev/disk:/dev/disk:ro -d --network
> monitoring ibmcom/cadvisor-s390x:0.33.0
>
> Perhaps I'm looking at things the wrong way, but my current understanding
> is:
> Cadvisor (and also Nodeexporter) collect various usage stats;
> Prometheus then gathers that data and does some sort of pre-processing of
> it (it doesn't tell Cadvisor to 'do something' - it just passively makes
> use of the data that Cadvisor collects)
> Grafana takes the data from Prometheus and uses it to generate various
> graphs/tables/reports.
>
> My situation is that when I run Cadvisor on it's own - no other containers
> at all - then it floods as many processors as I define in the zcx
> start.json file.
>
> Whilst Cadvisor is running, I can go to the relevant web-page and I can
> see that it is producing meters/charts, etc all on its own. Since that is
> the case, what is the point of Grafana?
>
> I have a Prometheus.yml file that features the term 'scrape_interval' (but
> not 'housekeeping'), but that file is for use by Prometheus, isn't it? How
> does it affect the amount of work that Cadvisor is doing, since I haven't
> even started that container yet?
>
> Regards
> Sean
>
> On Wed, 26 Aug 2020 at 23:05, Attila Fogarasi  wrote:
>
>> Check your values for housekeeping interval and scrape_interval.
>> Recommended is 15s and 30s (which makes for a 60 second rate window).
>> Small value for housekeeping interval will cause cAdvisor cpu usage to be
>> high, while scrape_interval affects Prometheus cpu usage.  It is entirely
>> possible to cause data collection to use 100% of the z/OS cpu -- remember
>> that on Unix systems the rule of thumb is 40% overhead for uncaptured cpu
>> time while z/OS is far more efficient and runs well under 10%.  You will
>> see this behaviour in zCX containers, it isn't going to measure the same
>> as
>> z/OS workload.  The optimizations in Unix have the premise that cpu time
>> is
>> low cost (as is memory), while z/OS considers cpu to be high cost and path
>> length worth saving.  Same for the subsystems in z/OS and performance
>> monitors.
>>
>> On Wed, Aug 26, 2020 at 11:43 PM Sean Gleann 
>> wrote:
>>
>> > Allan - "...count the beans differently...' Yes, I'm beginning to get
>> used
>> > to that concept. For instance, with the CPU Utilisation data that I
>> *have*
>> > been able to retrieve, the metric given is not 'CPU%', but 'Number of
>> > cores'. I'm having to do some rapid re-orienting to my way of thinking.
>> > As for the memory size, I've got "mem-gb" : 2 defined in my start.json
>> > file, but I've not seen any indication of paging load at all in my
>> testing.
>> >
>> > Michael - 5 zIIPs?   I wish!  Nope - these are all general-purpose
>> > processors.
>> > The z/OS system I'm using is a z/VM guest on a system run by an external
>> > supplier, so I'm not sure if defining zIIPs would actually achieve
>> anything
>> > (Is it possible to dedicate a zIIP engine to a specific z/VM guest?
>> That's
>> > a road I've not yet gone down).
>> > With regard to the WLM definitions, I followed the advice in the red
>> book
>> > and I'm reasonably certain I've got it right. Having said that,
>> cross-refer
>> > to a thread that I started earlier this week, titled "WLM Query"
>> > The response to that led to me defining a resource group to cap the
>> > started task to 10MSU, which resulted in a CPU% Util value of roughly
>> 5% -
>> > something I could be happy with.
>> > Under that cap, the started task ran, yes, but it ran like a
>> three-legged
>> > dog (my apologies to limb-count-challenged canines).
>> > Start-up of the task, from the START comma

Re: ZCX task monitoring, anyone?

[Sean Gleann]

Hi Attila - thanks for the pointers, but I'm not sure of how to act upon
them.

The start-up for Cadvisor that I'm using doesn't feature any pointer to a
parameter list, and despite much googling I don't see any mention of such a
thing. Everything keeps referring back to Prometheus and then on to Grafana
My Cadvisor start-up (taken directly from the IBM Red Book and slightly
modified to comply with local restrictions):
docker network create monitoring
docker run --name cadvisor -v /sys:/sys:ro -v
/var/lib/docker/:/var/lib/docker:ro -v /dev/disk:/dev/disk:ro -d --network
monitoring ibmcom/cadvisor-s390x:0.33.0

Perhaps I'm looking at things the wrong way, but my current understanding
is:
Cadvisor (and also Nodeexporter) collect various usage stats;
Prometheus then gathers that data and does some sort of pre-processing of
it (it doesn't tell Cadvisor to 'do something' - it just passively makes
use of the data that Cadvisor collects)
Grafana takes the data from Prometheus and uses it to generate various
graphs/tables/reports.

My situation is that when I run Cadvisor on it's own - no other containers
at all - then it floods as many processors as I define in the zcx
start.json file.

Whilst Cadvisor is running, I can go to the relevant web-page and I can see
that it is producing meters/charts, etc all on its own. Since that is the
case, what is the point of Grafana?

I have a Prometheus.yml file that features the term 'scrape_interval' (but
not 'housekeeping'), but that file is for use by Prometheus, isn't it? How
does it affect the amount of work that Cadvisor is doing, since I haven't
even started that container yet?

Regards
Sean

On Wed, 26 Aug 2020 at 23:05, Attila Fogarasi  wrote:

> Check your values for housekeeping interval and scrape_interval.
> Recommended is 15s and 30s (which makes for a 60 second rate window).
> Small value for housekeeping interval will cause cAdvisor cpu usage to be
> high, while scrape_interval affects Prometheus cpu usage.  It is entirely
> possible to cause data collection to use 100% of the z/OS cpu -- remember
> that on Unix systems the rule of thumb is 40% overhead for uncaptured cpu
> time while z/OS is far more efficient and runs well under 10%.  You will
> see this behaviour in zCX containers, it isn't going to measure the same as
> z/OS workload.  The optimizations in Unix have the premise that cpu time is
> low cost (as is memory), while z/OS considers cpu to be high cost and path
> length worth saving.  Same for the subsystems in z/OS and performance
> monitors.
>
> On Wed, Aug 26, 2020 at 11:43 PM Sean Gleann 
> wrote:
>
> > Allan - "...count the beans differently...' Yes, I'm beginning to get
> used
> > to that concept. For instance, with the CPU Utilisation data that I
> *have*
> > been able to retrieve, the metric given is not 'CPU%', but 'Number of
> > cores'. I'm having to do some rapid re-orienting to my way of thinking.
> > As for the memory size, I've got "mem-gb" : 2 defined in my start.json
> > file, but I've not seen any indication of paging load at all in my
> testing.
> >
> > Michael - 5 zIIPs?   I wish!  Nope - these are all general-purpose
> > processors.
> > The z/OS system I'm using is a z/VM guest on a system run by an external
> > supplier, so I'm not sure if defining zIIPs would actually achieve
> anything
> > (Is it possible to dedicate a zIIP engine to a specific z/VM guest?
> That's
> > a road I've not yet gone down).
> > With regard to the WLM definitions, I followed the advice in the red book
> > and I'm reasonably certain I've got it right. Having said that,
> cross-refer
> > to a thread that I started earlier this week, titled "WLM Query"
> > The response to that led to me defining a resource group to cap the
> > started task to 10MSU, which resulted in a CPU% Util value of roughly 5%
> -
> > something I could be happy with.
> > Under that cap, the started task ran, yes, but it ran like a three-legged
> > dog (my apologies to limb-count-challenged canines).
> > Start-up of the task, from the START command to the "server is
> > listening..." message took over an hour, and
> > STOP-command-to-task-termination took approx. 30 minutes.
> > (SSH-ing to the task was a bit of a joke, too. Responses to simple
> commands
> > like 'docker ps -a' could be seen 'painting' across the screen,
> > character-by-character...)
> > As a result, I've moved away from trying to limit the task for the time
> > being. I'm concentrating on attempting to get cadvisor to be a bit less
> > greedy.
> >
> > Regards
> > Sean
> >
> > On Wed, 26 Aug 2020 at 13:49, Michael Babcock 
> > wrote:
> >
> > > I can’t check my zCX out right now si

Re: ZCX task monitoring, anyone?

[Sean Gleann]

Allan - "...count the beans differently...' Yes, I'm beginning to get used
to that concept. For instance, with the CPU Utilisation data that I *have*
been able to retrieve, the metric given is not 'CPU%', but 'Number of
cores'. I'm having to do some rapid re-orienting to my way of thinking.
As for the memory size, I've got "mem-gb" : 2 defined in my start.json
file, but I've not seen any indication of paging load at all in my testing.

Michael - 5 zIIPs?   I wish!  Nope - these are all general-purpose
processors.
The z/OS system I'm using is a z/VM guest on a system run by an external
supplier, so I'm not sure if defining zIIPs would actually achieve anything
(Is it possible to dedicate a zIIP engine to a specific z/VM guest? That's
a road I've not yet gone down).
With regard to the WLM definitions, I followed the advice in the red book
and I'm reasonably certain I've got it right. Having said that, cross-refer
to a thread that I started earlier this week, titled "WLM Query"
The response to that led to me defining a resource group to cap the
started task to 10MSU, which resulted in a CPU% Util value of roughly 5% -
something I could be happy with.
Under that cap, the started task ran, yes, but it ran like a three-legged
dog (my apologies to limb-count-challenged canines).
Start-up of the task, from the START command to the "server is
listening..." message took over an hour, and
STOP-command-to-task-termination took approx. 30 minutes.
(SSH-ing to the task was a bit of a joke, too. Responses to simple commands
like 'docker ps -a' could be seen 'painting' across the screen,
character-by-character...)
As a result, I've moved away from trying to limit the task for the time
being. I'm concentrating on attempting to get cadvisor to be a bit less
greedy.

Regards
Sean

On Wed, 26 Aug 2020 at 13:49, Michael Babcock  wrote:

> I can’t check my zCX out right now since my internet is down.
>
> You are running these on zIIP engines correct? Must be nice to have 5
> zIIPs!  And have the WLM parts in place?   Although it probably wouldn’t
> make much difference during startup/shutdown.
>
> On Wed, Aug 26, 2020 at 3:40 AM Sean Gleann  wrote:
>
> > Can anyone offer advice, please, with regard to monitoring the system
> >
> > resource consumption of a zcx Container task?
> >
> >
> >
> > I've got a zcx Container task running on a 'sandbox' system where - as
> yet
> >
> > - I'm not collecting any RMF/SMF data. Because of that, my only source of
> >
> > system usage is the SDSF DA panel. I feel that the numbers I see there
> >
> > are... 'questionable' is the best word I can think of.
> >
> >
> >
> > Firstly, the EXCP-count for the task goes up to about 15360 during the
> >
> > initial start-up phase, but then it stays there until the STOP command is
> >
> > issued. At that point, EXCP-count starts rising again, until the task
> >
> > finally terminates. The explanation for that is probably because all the
> >
> > I/O is being handled internally at the 'Linux' level - the task must be
> >
> > doing *some* I/O, right? - but the data isn't getting back to SDSF for
> some
> >
> > reason. Without the benefit of SMF data to examine, I'm wondering if this
> >
> > is part of a larger problem.
> >
> >
> >
> > The other thing that troubles me is the CPU% busy value. My sandbox
> system
> >
> > has 5 engines defined, and in the 'start.json' file that controls the zcx
> >
> > Container task, I've specified a 'cpu' value of 4. During the start-up
> >
> > phase for the Container started task, SDSF shows CPU% values of approx
> 80%,
> >
> > but when the task is finally initialised, this drops to 'tickover' rates
> of
> >
> > about 1%. I'm happy with that - the initial start-up of *any* task as
> >
> > complex as a zcx Container is likely to cause high CPU usage, and the
> >
> > subsequent drop to the 1% levels is fine by me.
> >
> >
> >
> > But... Once the Container task is started and I've ssh'd into it, I then
> >
> > want to monitor its 'internal' system consumption. I've been using the
> >
> > 'Getting Started...' redbook as my guide throughout all this project, and
> >
> > it talks about using "Nodeexporter", "Cadvisor", "Prometheus" and
> "Grafana"
> >
> > as tools for this. I've got all those things installed and I can start
> and
> >
> > stop them quite happily, but I've found that using Cadvisor on it's own
> can
> >
> > drive CPU% levels back up to 80% for the entire time it is running. If a
> >
> > system is

ZCX task monitoring, anyone?

[Sean Gleann]

Can anyone offer advice, please, with regard to monitoring the system
resource consumption of a zcx Container task?

I've got a zcx Container task running on a 'sandbox' system where - as yet
- I'm not collecting any RMF/SMF data. Because of that, my only source of
system usage is the SDSF DA panel. I feel that the numbers I see there
are... 'questionable' is the best word I can think of.

Firstly, the EXCP-count for the task goes up to about 15360 during the
initial start-up phase, but then it stays there until the STOP command is
issued. At that point, EXCP-count starts rising again, until the task
finally terminates. The explanation for that is probably because all the
I/O is being handled internally at the 'Linux' level - the task must be
doing *some* I/O, right? - but the data isn't getting back to SDSF for some
reason. Without the benefit of SMF data to examine, I'm wondering if this
is part of a larger problem.

The other thing that troubles me is the CPU% busy value. My sandbox system
has 5 engines defined, and in the 'start.json' file that controls the zcx
Container task, I've specified a 'cpu' value of 4. During the start-up
phase for the Container started task, SDSF shows CPU% values of approx 80%,
but when the task is finally initialised, this drops to 'tickover' rates of
about 1%. I'm happy with that - the initial start-up of *any* task as
complex as a zcx Container is likely to cause high CPU usage, and the
subsequent drop to the 1% levels is fine by me.

But... Once the Container task is started and I've ssh'd into it, I then
want to monitor its 'internal' system consumption. I've been using the
'Getting Started...' redbook as my guide throughout all this project, and
it talks about using "Nodeexporter", "Cadvisor", "Prometheus" and "Grafana"
as tools for this. I've got all those things installed and I can start and
stop them quite happily, but I've found that using Cadvisor on it's own can
drive CPU% levels back up to 80% for the entire time it is running. If a
system is running flat-out when all it is doing is monitoring itself, well,
there's something wrong somewhere... I'm trying to find an idiot's guide to
controlling what Cadvisor does, but as yet I've been unsuccessful.

Regards
Sean

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

Re: WLM query

[Sean Gleann]

Thank you, Massimo - that solved the problem.

'Resource Group' is something I've never used before - my WLM expertise
stopped developing about 15 years ago & ISTR the concept just didn't exist
back then.

Regards
Sean

On Mon, 24 Aug 2020 at 09:22, Massimo Biancucci  wrote:

> Sean,
>
> AFAIK WLM runs and manages continuously the workload setting DP as needed
> (if there's no CPU contention ... so no problems).
>
> Its main task is to make all the AS as fast as they can.
>
> If there's available CPU for everybody every AS will take as much as it
> can.
>
> If you want a single (or group of) AS to be limited you can use a capping
> based on a Resource Group (WLM menu option 3) to set a maximum of MSUs
> available for that group.
> You have to use a classification to assign the AS to that RG too.
>
> Hope this helps.
> Best regards.
> Max
>
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> Mail
> priva di virus. www.avast.com
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Il giorno lun 24 ago 2020 alle ore 10:10 Sean Gleann <
> sean.gle...@gmail.com>
> ha scritto:
>
> > Is there a way to force a maximum CPU% utilisation for a specific task?
> >
> > Please correct me if I'm wrong here, but it is my understanding that WLM
> > only really starts 'doing it's stuff' when the system as a whole is
> heavily
> > loaded.
> > For example:
> >  - If my system is running at 80%, and a new incoming task wants 50% CPU,
> > then it is allowed to run, but it only gets a maximum of 20% (obviously),
> > and WLM starts switching task dispatch priorities around to try and
> > maintain the service levels defined in the policy.
> >  - On the other hand, if the system is only 20% busy and the 50%-usage
> task
> > comes along, then it is allowed to run and WLM just lets it happen
> >
> > What I want to do is to limit specific tasks to a maximum CPU% value no
> > matter what the overall loading is.
> >
> > Regards
> > Sean
> >
> > --
> > 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

WLM query

[Sean Gleann]

Is there a way to force a maximum CPU% utilisation for a specific task?

Please correct me if I'm wrong here, but it is my understanding that WLM
only really starts 'doing it's stuff' when the system as a whole is heavily
loaded.
For example:
 - If my system is running at 80%, and a new incoming task wants 50% CPU,
then it is allowed to run, but it only gets a maximum of 20% (obviously),
and WLM starts switching task dispatch priorities around to try and
maintain the service levels defined in the policy.
 - On the other hand, if the system is only 20% busy and the 50%-usage task
comes along, then it is allowed to run and WLM just lets it happen

What I want to do is to limit specific tasks to a maximum CPU% value no
matter what the overall loading is.

Regards
Sean

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

Re: (yet another) problem with zcx container

[Sean Gleann]

I hear what you say, Brian - perhaps I should be a little less trusting.
Nevertheless, the book goes on to cover installation of 'Cadvisor' and
'Prometheus', too, both of which are required for grafana to do its job.
(and I'm having similar difficulty with Cadvisor, too.)

Regards
Sean


On Fri, 14 Aug 2020 at 12:15, David Crayford  wrote:

> I doubt it would be in production if it wasn't ready :)
>
> On 2020-08-14 4:32 PM, Brian Westerman wrote:
> > I hate to say this but I can't help myself, but what makes you think
> they actually got it to work?  :)
> >
> > But seriously, the redbooks are written sometimes before the final
> processes are set in place, so sometimes they tell you what "should be"
> instead of what "is be".
> >
> >  From what you are saying, your way should certainly work, but it's hard
> to debug without the entire process to look at and implement myself.
> >
> > Brian
> >
> > --
> > 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

(yet another) problem with zcx container

[Sean Gleann]

Hoping that someone can help me out here...

I'm successfully running a zcx container task on a z/OS 2.4 platform, and
now I'm trying to get 'grafana' running to show me various system
performance stats, etc.

According to the RedBook "Getting started with zOS Container Extensions
and Docker", section 7.6.1 says that I have to 'Install Node-Exporter'.
Following through the example commands, the container build appears to work
OK, but the documented 'run' command fails when the specified bind mount
for "/:/rootfs:ro" is included. The error message is:

docker: Error response from daemon: authorization denied by plugin
zcxauthplugin: Request to bind mount the path "/" with ro mode is disabled
for Docker running on IBM zCX appliance instance.

If I take out that particular term in the run command, then it apparently
works OK, but a 'docker ps -a' command immediately afterwards shows the
container status as 'Exited (1) *n* seconds ago'.

All of that begs the question: "How did the RedBook authors manage to get
things to work?" I must have missed some small vital step somewhere, but
currently I'm failing to see what it might be.

Regards
Sean

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

Re: RMM Scratch Processing

[Sean Gleann]

On the face of things, someone has changed the Vital Records Specification
somewhere along the line.
This, along with the VRSCHANGE option setting in PARMLIB(EDGRMMxx) -
whatever the DFRMM started task JCL points to - is what is preventing you
from continuing.
I don't know if that setting can be temporarily over-ridden, but
manual-bashing may solve that.
Alternatively, change the VRSCHANGE option value to INFO and refresh the
parameters in DFRMM with a 'Modify' command (I think! - more manual-bashing
required)
That should allow you to achieve your aim.
Naturally I'd suggest changing the value back afterward - such warnings are
provided for a purpose.

Regards
Sean


On Wed, 5 Aug 2020 at 12:19, Mark Jacobs <
0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> Thanks. It did. Now to see what this means.
>
> EDG2308I CHANGES HAVE BEEN MADE TO VRS POLICIES SINCE THE PREVIOUS
> INVENTORY MANAGEMENT RUN
> EDG2311I INVENTORY MANAGEMENT STOPPING BECAUSE OF VRSCHANGE(VERIFY) OPTION
> EDG6901I UTILITY EDGHSKP COMPLETED WITH RETURN CODE 12
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, August 5, 2020 3:27 AM, Sean Gleann 
> wrote:
>
> > The scratch job JCL should also have a DD with DDName 'MESSAGE'.
> > You might find more/better information in that file
> >
> > Sean
> >
> > On Wed, 5 Aug 2020 at 08:08, Gibney, Dave gib...@wsu.edu wrote:
> >
> > > I am not using RMM, but I would expect the utility EDGHSKP to have
> > > documentation and an explanation of RC 12.
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> > > > Behalf Of Mark Jacobs
> > > > Sent: Tuesday, August 04, 2020 9:11 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: RMM Scratch Processing
> > > > This is all I'm getting, nothing else.
> > > > EDG6202E FAILURE DURING DFSMSrmm SUBSYSTEM PROCESSING
> > > > EDG6901I UTILITY EDGHSKP COMPLETED WITH RETURN CODE 12
> > > > Mark Jacobs
> > > > Sent from ProtonMail, Swiss-based encrypted email.
> > > > GPG Public Key -
> > > >
> https://urldefense.com/v3/https://api.protonmail.ch/pks/lookup?op=get
> > > >
> > > > =markjac...@protonmail.com
> ;!!JmPEgBY0HMszNaDT!7J--CkqfH3NkPR86ASrtKKL1JysLyYwHWCGqpNEeFXC54UZUwARZKPHAKjv6Xw$
> > > > ‐‐‐ Original Message ‐‐‐
> > > > On Tuesday, August 4, 2020 9:42 PM, Gibney, Dave gib...@wsu.edu
> > > > wrote:
> > > >
> > > > > And the msg error is?
> > > > >
> > > > > > -Original Message-
> > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> > > > > > Behalf Of Mark Jacobs
> > > > > > Sent: Tuesday, August 04, 2020 6:22 PM
> > > > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > > > Subject: Re: RMM Scratch Processing
> > > > > > Yea. I've looked at that manual, found the job. Ran it, failed
> > > > > > without
> > > > > > giving
> > > >
> > > > > > me any meaningful information.
> > > > > > Mark Jacobs
> > > > > > Sent from ProtonMail, Swiss-based encrypted email.
> > > > > > GPG Public Key -
> > > >
> > > >
> https://urldefense.com/v3/https://api.protonmail.ch/pks/lookup?op=get
> > > >
> > > > > >
> > > >
> > > > =markjac...@protonmail.com;!!JmPEgBY0HMszNaDT!9aPYApXHdTv
> > > > JhtptCABSdFPMaTba4-xuRvYqJ3hkFpjy6Vhi47iUg7ht6qo8AA$
> > > >
> > > > > > ‐‐‐ Original Message ‐‐‐
> > > > > > On Tuesday, August 4, 2020 9:19 PM, Roger Lowe
> > > > > > roger_l...@bigpond.com wrote:
> > > > > >
> > > > > > > On Tue, 4 Aug 2020 16:10:43 +, Mark Jacobs
> > > > > > > markjac...@protonmail.com wrote:
> > > > > > >
> > > > > > > > I know next to nothing about RMM, and need to mark some
> tapes in
> > > > > > > > its
> > > > >
> > > > > > > > database as scratch, I have one tape (might be others too)
> that
> > > > > > > > are in
> > > > > > > > USER
> > > >
> > > > > > > &g

Re: RMM Scratch Processing

[Sean Gleann]

The scratch job JCL should also have a DD with DDName 'MESSAGE'.
You might find more/better information in that file

Sean

On Wed, 5 Aug 2020 at 08:08, Gibney, Dave  wrote:

> I am not using RMM, but I would expect the utility EDGHSKP to have
> documentation and an explanation of RC 12.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Mark Jacobs
> > Sent: Tuesday, August 04, 2020 9:11 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: RMM Scratch Processing
> >
> > This is all I'm getting, nothing else.
> >
> > EDG6202E FAILURE DURING DFSMSrmm SUBSYSTEM PROCESSING
> > EDG6901I UTILITY EDGHSKP COMPLETED WITH RETURN CODE 12
> >
> > Mark Jacobs
> >
> > Sent from ProtonMail, Swiss-based encrypted email.
> >
> > GPG Public Key -
> > https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get
> > =markjacobs@protonmail.com__;!!JmPEgBY0HMszNaDT!7J--
> > CkqfH3NkPR86ASrtKKL1JysLyYwHWCGqpNEeFXC54UZUwARZKPHAKjv6Xw$
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Tuesday, August 4, 2020 9:42 PM, Gibney, Dave 
> > wrote:
> >
> > > And the msg error is?
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> > > > Behalf Of Mark Jacobs
> > > > Sent: Tuesday, August 04, 2020 6:22 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: RMM Scratch Processing
> > > > Yea. I've looked at that manual, found the job. Ran it, failed
> without
> > giving
> > > > me any meaningful information.
> > > > Mark Jacobs
> > > > Sent from ProtonMail, Swiss-based encrypted email.
> > > > GPG Public Key -
> > > >
> > https://urldefense.com/v3/https://api.protonmail.ch/pks/lookup?op=get
> > > >
> > > >
> > =markjac...@protonmail.com;!!JmPEgBY0HMszNaDT!9aPYApXHdTv
> > JhtptCABSdFPMaTba4-xuRvYqJ3hkFpjy6Vhi47iUg7ht6qo8AA$
> > > > ‐‐‐ Original Message ‐‐‐
> > > > On Tuesday, August 4, 2020 9:19 PM, Roger Lowe
> > > > roger_l...@bigpond.com wrote:
> > > >
> > > > > On Tue, 4 Aug 2020 16:10:43 +, Mark Jacobs
> > > > > markjac...@protonmail.com wrote:
> > > > >
> > > > > > I know next to nothing about RMM, and need to mark some tapes in
> > its
> > > > > > database as scratch, I have one tape (might be others too) that
> are in
> > USER
> > > > > > status and its expdt has passed. I know that "something" needs
> to be
> > done
> > > > > > to make it a scratch tape, but everything I've tried has failed.
> Can
> > someone
> > > > > > assist?
> > > > >
> > > > > Mark,
> > > > > Have a look in the DFSMSrmm Implementation and Customization
> > Guide -
> > > > > it has sample jcl that could be used 
> > > > > Roger
> > > >
> > > > > 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
>

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

Re: AZD messages?

[Sean Gleann]

That's great news, Michael!!
I managed to finally(!) get that step3.2 to run successfully at the end of
yesterday.
I'm seeing pretty much the same sort of info as you are seeing.
Have spent today de-provisioning the existing container and going through
the provisioning process once more
Will see what tomorrow brings...

Regards
Sean

On Tue, 9 Jun 2020 at 18:59, Michael Babcock  wrote:

> Sean,
>
> Good News!  I successfully started a zCX instance and logged on via OMVS
> and used the ssh command to reach the zCX instance.  I also successfully
> logged on via a Bluezone VT320 session pointing to our DVIPA address.  I
> had to transfer the admin IDs private key to my PC, convert it to ppk
> format (using Puttygen) and import that in Bluezone’s session.   Woohoo!
>
> For the “Retrieve Workflow Version” step (3.2) Here’s the request tab
> (I’ve obscured certain details, like https://mysystem.mycompany, etc).
>
> HTTP method:
> GET
> Request:
>
> https://mysystem.mycompany:43200/zosmf/workflow/rest/1.0/workflows/d17d4bf9-4467-41b7-8e6c-ec8d47c40997
>
> And this is what I get in the Response tab.  Also don’t forget, in the
> Status tab, the expected return code is 200, my actual return is 200.
>
>
> {
> "access": "Public",
> "accountInfo": null,
> "automationStatus": null,
> "category": "provisioning",
> "containsParallelSteps": false,
> "deleteCompletedJobs": false,
> "globalVariableGroup": null,
> "isCallable": null,
> "jobStatement": null,
> "owner": "",
> "percentComplete": 9,
> "productID": "HZDC7C0",
> "productName": "IBM z\/OS Container Extensions",
> "productVersion": "V2R4.1.0",
> "scope": "none",
> "softwareType": "IBM-zCX",
> "statusName": "in-progress",
> "system": "mySplex.mySystem",
> "vendor": "IBM",
> "workflowDefinitionFileMD5Value": "11b08002b4648a0778c35c76dcbe9f64",
> "workflowDescription": "Provision a IBM zOS Container Extensions
> Appliance Instance.",
> "workflowID": "zOS_Container_Extensions_Provision",
> "workflowKey": "d17d4bf9-4467-41b7-8e6c-ec8d47c40997",
> "workflowName": "Provision a IBM zOS Container Extensions Appliance
> Instance. - Workflow",
> "workflowVersion": "1.0.18"
> }
>
> On 6/8/2020 7:16 AM, Sean Gleann wrote:
> > Thanks for the hint about thoroughly checking output, Michael.
> > I went back and studied all the saved outputs, hoping to find something
> > that might be helpful.
> > In the event, there were no indications of such problems - no error
> > messages or non-zero return codes - but it's as well to be sure.
> >
> > Can I ask you for more information regarding what you see with the '3.2
> > Retrieve Workflow version' step, please?
> > For me, I get to the point of clicking 'Perform' on this step, and I see
> > that z/OSMF is about to use the REST API with the request
> >
> >
> https://localhost:10443/zosmf/workflow/rest/1.0/workflows/3ca56936-9a81-48a0-94d9-84e28ee2d842
> > :
> >
> > Clicking 'Next' on this results in:
> >
> > IZUWFE: The request cannot be completed because an error occurred.
> The
> > following error data is returned: "EDC8128I Connection refused.
> > (errno2=0x76630291) (Connection refused)"
> >
> > and so I am forced to click on 'Finish' if I am to proceed.
> > What do you see during this sequence?
> >
> > I suspect that it's the 'localhost:10443' bit that is the root of the
> > problem, but I'm unsure how to circumvent it, or even to correct the
> > problem.
> > As I said earlier in this thread, I'm working through a tunnelled SSH
> > connection to access my z/OSMF. In the main, this is working quite
> happily.
> > That connection definition associates my desktop system's local port
> 10443
> > with the hosts systems' 10443, and the URL I use to access z/OSMF is
> > https://localhost:10443/zosmf.
> > So I'm at a bit of a loss in understanding why the connection should be
> > refused.
> >
> > Regards
> > Sean
> >
> >
> > On Fri, 5 Jun 2020 at 04:08, Michael Babcock 
> wrote:
> >
> >> Oh and beware, just because the Verify Feature Bits job (and a couple of
> >> others)

Re: AZD messages?

[Sean Gleann]

Mike
I can see I left out details that would have made things a bit easier to
understand - Please accept my apologies.
Having said that, the first draft of a response to the points you raise
included a _lot_ of information, and I eventually threw that draft away.
Please understand that I'm not trying to be secretive - I'm just trying to
avoid a 'TL/DR' response.
My use of localhost is Ok in the environment I'm in. I can use that or the
DNS name, or the IPaddress - they are all practically interchangeable for
my purposes.
Note the word 'practically' there, though. If I use DNS or IPAddr to get to
z/OSMF, I get a security warning in the browser window which I have to
respond to before getting to the logon screen.
If I use localhost, that warning does not appear, so really it's just a way
of saving a (small) amount of time.

Your later comments about the z/OSMF server certificate coincided with my
recognition of the significance of the KEYRING_NAME parm in IZUPRMxx.
My only prior use of z/OSMF was to use the Configuration Assistant to
create the config files necessary for implementing AT-TLS on the system.
After a few false starts (it was my _very_ first use of z/OSMF) everything
went fine, and there were no instances of z/OSMF wanting to use the REST
API to get information from somewhere else, so no 'connection refused'
problem occurred.
I've never modified and used the supplied IZUSEC job because I haven't
needed to. Everything was previously done by the team that created our z/OS
system in the first place - or so I thought.
With this current use of z/OSMF, the use of a server certificate has raised
its head.
Now it would appear that I've got to put some work in on that front; to
make sure all the RACF permissions are in place and so on.

But I'm a bit confused. On the one hand I can see the need for the
correct definition and handling of the server certificate, but APAR PH10056
says (in part):

The z/OSMF server port uses Java SSL encryption to protect its
outbound HTTPS connections. Therefore, it is not necessary (or
possible) to configure AT-TLS on the z/OSMF server port. If you
attempt to do so, the z/OSMF server will encounter HTTP connection
failures and errors, such as the following, in the server logs
directory:
1.  IZUG476E: The HTTP request to the secondary z/OSMF instance "209"
failed with error type "CertificateError" and response code "0"
2.  javax.net.ssl.SSLException: Unrecognized SSL message, plaintext 
connection?

That second error message is exactly the one I'm seeing in the server log
at the time the 'connection refused' error occurs.

So right now I'm at a bit of a loss when it comes to reconciling the
apparent contradiction here. As I say, I've never touched the IZUSEC job it
appears but it _has_ been used and is now interfering with z/OSMF's
activities.
I _have_ introduced AT-TLS on the system, but that is restricted to
controlling TN3270 and SFTP work - there's no mention of port 10443 or
stuff associated with z/OSMF in the AT-TLS config files.
I 've obviously got some more digging to do...


Regards
Sean


On Tue, 9 Jun 2020 at 07:43, Sean Gleann  wrote:

> Thank you Dave - I was unaware of that qualification.
> Checked and, yes, 'localhost' is defined in my RESOLVER parameters
>
> Sean
>
>
> On Mon, 8 Jun 2020 at 17:33, Mike Wawiorko <
> 014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote:
>
>> I hope I'm understanding what you are saying.
>>
>> Localhost is for use ONLY within a single TCPIP stack or system. It is
>> another way of writing non-routable IP address '127.0.0.1'.
>> Maybe configuring host files will allow you to do this but that will be
>> very confusing and awkward to support.
>>
>> You should NOT be using localhost to get from your device (PC or
>> whatever) to the z/OS TCPIP stack.
>>
>> You should configure a name for your ZOSMF IP address.
>> If you always run ZOSMF on the same z/OS system you may already have a
>> suitable name in DNS for the system's static VIPA.
>> If you move ZOSMF between systems in the sysplex you will need a Dynamic
>> Virtual IP Address (DVIPA) and an entry in DNS (or host files) for it.
>>
>> I'm struggling to follow what you are saying about PuTTY for SSH and your
>> Opera browser.
>>
>> You might use your SSH connection to get to z/OS and work with USS and
>> perform some configuration actions. You do not use PuTTY to logon to ZOSMF.
>>
>> You should have a ZOSMF server certificate signed by a CA trusted by your
>> browser.
>> This certificate should - probably must - include the DNS name as a
>> subject alternate name.
>>
>> When you make the HTTPS connection from the browser Opera will validate
>> the security of the connection. That will include:
>> 1. Check that it is indeed

Re: AZD messages?

[Sean Gleann]

Thank you Dave - I was unaware of that qualification.
Checked and, yes, 'localhost' is defined in my RESOLVER parameters

Sean


On Mon, 8 Jun 2020 at 17:33, Mike Wawiorko <
014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote:

> I hope I'm understanding what you are saying.
>
> Localhost is for use ONLY within a single TCPIP stack or system. It is
> another way of writing non-routable IP address '127.0.0.1'.
> Maybe configuring host files will allow you to do this but that will be
> very confusing and awkward to support.
>
> You should NOT be using localhost to get from your device (PC or whatever)
> to the z/OS TCPIP stack.
>
> You should configure a name for your ZOSMF IP address.
> If you always run ZOSMF on the same z/OS system you may already have a
> suitable name in DNS for the system's static VIPA.
> If you move ZOSMF between systems in the sysplex you will need a Dynamic
> Virtual IP Address (DVIPA) and an entry in DNS (or host files) for it.
>
> I'm struggling to follow what you are saying about PuTTY for SSH and your
> Opera browser.
>
> You might use your SSH connection to get to z/OS and work with USS and
> perform some configuration actions. You do not use PuTTY to logon to ZOSMF.
>
> You should have a ZOSMF server certificate signed by a CA trusted by your
> browser.
> This certificate should - probably must - include the DNS name as a
> subject alternate name.
>
> When you make the HTTPS connection from the browser Opera will validate
> the security of the connection. That will include:
> 1. Check that it is indeed HTTPS and not HTTP
> 2. Check for TLS1.2 - lower levels of SSL / TLS are often not allowed
> these days
> 3. Check the ZOSMF server certificate Is signed by a CA trusted by Opera
> 4. Check certificate dates
> 5. Confirm the DNS you used to reach ZOSMF is named as a subject alternate
> name
>
> Browsers have an icon to click showing why a connection is not secure. It
> will very likely be one of the steps above.
>
> Some browsers allow you to allow connections with an untrusted
> certificate. That would be a bad security practice but may allow an initial
> connection.
>
> Hope some of this helps. It is generic advice for any browser connection
> to z/OS.
>
> Mike Wawiorko
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Sean Gleann
> Sent: 08 June 2020 14:15
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: AZD messages?
>
>
> This message originated from outside our organisation and is from web
> based email - sean.gle...@gmail.com
>
> As far as I understand things, 'localhost' is just another way of saying
> '127.0.0.1' meaning 'this computer', so - yes, localhost is defined.
> I have an SSH connection defined in PuTTY that associates my local 10443
> with the host system's 10443, and I start that connection before attempting
> to go to https://localhost:10443 in my browser (Opera).
> I'm quite happy to be shown any error in my understanding, however.
>
> But you've sparked off another train of thought, Lloyd.
> Whilst it's true I get to my z/OSMF with 'https://localhost:10443/zosmf',
> the very first thing I see is a warning that the connection is not secure
> and I have to click on 'continue anyway' in order to get to the z/OSMF
> sign-on screen.
> I think I've got to sort out *that* problem before trying to go any
> further.
>
> Regards
> Sean
>
> ,
>
>
> This e-mail and any attachments are confidential and intended solely for
> the addressee and may also be privileged or exempt from disclosure under
> applicable law. If you are not the addressee, or have received this e-mail
> in error, please notify the sender immediately, delete it from your system
> and do not copy, disclose or otherwise act upon any part of this e-mail or
> its attachments.
> Internet communications are not guaranteed to be secure or virus-free. The
> Barclays Group does not accept responsibility for any loss arising from
> unauthorised access to, or interference with, any Internet communications
> by any third party, or from the transmission of any viruses. Replies to
> this e-mail may be monitored by the Barclays Group for operational or
> business reasons.
> Any opinion or other information in this e-mail or its attachments that
> does not relate to the business of the Barclays Group is personal to the
> sender and is not given or endorsed by the Barclays Group.
> Barclays Execution Services Limited provides support and administrative
> services across Barclays group. Barclays Execution Services Limited is an
> appointed representative of Barclays Bank UK plc, Barclays Bank plc and
> Clydesdale Financial Serv

Re: AZD messages?

[Sean Gleann]

As far as I understand things, 'localhost' is just another way of saying
'127.0.0.1' meaning 'this computer', so - yes, localhost is defined.
I have an SSH connection defined in PuTTY that associates my local 10443
with the host system's 10443, and I start that connection before attempting
to go to https://localhost:10443 in my browser (Opera).
I'm quite happy to be shown any error in my understanding, however.

But you've sparked off another train of thought, Lloyd.
Whilst it's true I get to my z/OSMF with 'https://localhost:10443/zosmf',
the very first thing I see is a warning that the connection is not secure
and I have to click on 'continue anyway' in order to get to the z/OSMF
sign-on screen.
I think I've got to sort out *that* problem before trying to go any further.

Regards
Sean

,

On Mon, 8 Jun 2020 at 13:55, Lloyd Fuller  wrote:

> Is localhost defined?
>
> Sent from my iPad
>
> > On Jun 8, 2020, at 8:16 AM, Sean Gleann  wrote:
> >
> > Thanks for the hint about thoroughly checking output, Michael.
> > I went back and studied all the saved outputs, hoping to find something
> > that might be helpful.
> > In the event, there were no indications of such problems - no error
> > messages or non-zero return codes - but it's as well to be sure.
> >
> > Can I ask you for more information regarding what you see with the '3.2
> > Retrieve Workflow version' step, please?
> > For me, I get to the point of clicking 'Perform' on this step, and I see
> > that z/OSMF is about to use the REST API with the request
> >
> >
> https://localhost:10443/zosmf/workflow/rest/1.0/workflows/3ca56936-9a81-48a0-94d9-84e28ee2d842
> > :
> >
> > Clicking 'Next' on this results in:
> >
> > IZUWFE: The request cannot be completed because an error occurred.
> The
> > following error data is returned: "EDC8128I Connection refused.
> > (errno2=0x76630291) (Connection refused)"
> >
> > and so I am forced to click on 'Finish' if I am to proceed.
> > What do you see during this sequence?
> >
> > I suspect that it's the 'localhost:10443' bit that is the root of the
> > problem, but I'm unsure how to circumvent it, or even to correct the
> > problem.
> > As I said earlier in this thread, I'm working through a tunnelled SSH
> > connection to access my z/OSMF. In the main, this is working quite
> happily.
> > That connection definition associates my desktop system's local port
> 10443
> > with the hosts systems' 10443, and the URL I use to access z/OSMF is
> > https://localhost:10443/zosmf.
> > So I'm at a bit of a loss in understanding why the connection should be
> > refused.
> >
> > Regards
> > Sean
> >
> >
> >> On Fri, 5 Jun 2020 at 04:08, Michael Babcock 
> wrote:
> >>
> >> Oh and beware, just because the Verify Feature Bits job (and a couple of
> >> others) gets a zero condition code doesn’t mean it executed
> successfully.
> >> You have to check STDERR and STDOUT tabs.  Mine always gets a syntax
> >> error.
> >>
> >>> On Thu, Jun 4, 2020 at 10:05 AM Sean Gleann 
> wrote:
> >>>
> >>> It's been really quite a troublesome effort for me, Michael, but I
> guess
> >>> it's true to say that most of the problems are down to my rudimentary
> >>> knowledge of TCPIP and networking in general.
> >>> For various reasons, I have to use a tunnelled connection through to
> the
> >>> z/OS guest, and that makes things a bit more interesting.
> >>> The 'Getting Started' redbook (SG24-8457-00) has been my sole point of
> >>> reference all the way through, and yeah, it's OK - up to point. it
> >> doesn't
> >>> cover the tunnelling complication, naturally, and there are some very
> >> poor
> >>> typos to take into account.
> >>> As for the Workload Provisioning process in z/OSMF - after you've
> >> specified
> >>> a bunch of parameters, it's just a JCL generator/job submitter/checker
> >> with
> >>> a couple of z/OSMF-specific bits thrown in.
> >>> During the initial parameter specification phase I had considerable
> >>> difficulty at the point of specifying the RSA key, but eventually got
> it
> >>> right.
> >>> Step 3.2 in the process - where some sort of version information is
> >> looked
> >>> for - has always failed for me. I've never been able to make it work as
> >>> expected and have had to force it to a 'complete' state by clicking the
> >>> 'Finish' button.
> >>>
> >>> I tr

Re: AZD messages?

[Sean Gleann]

Thanks for the hint about thoroughly checking output, Michael.
I went back and studied all the saved outputs, hoping to find something
that might be helpful.
In the event, there were no indications of such problems - no error
messages or non-zero return codes - but it's as well to be sure.

Can I ask you for more information regarding what you see with the '3.2
Retrieve Workflow version' step, please?
For me, I get to the point of clicking 'Perform' on this step, and I see
that z/OSMF is about to use the REST API with the request

https://localhost:10443/zosmf/workflow/rest/1.0/workflows/3ca56936-9a81-48a0-94d9-84e28ee2d842
:

Clicking 'Next' on this results in:

IZUWFE: The request cannot be completed because an error occurred. The
following error data is returned: "EDC8128I Connection refused.
(errno2=0x76630291) (Connection refused)"

and so I am forced to click on 'Finish' if I am to proceed.
What do you see during this sequence?

I suspect that it's the 'localhost:10443' bit that is the root of the
problem, but I'm unsure how to circumvent it, or even to correct the
problem.
As I said earlier in this thread, I'm working through a tunnelled SSH
connection to access my z/OSMF. In the main, this is working quite happily.
That connection definition associates my desktop system's local port 10443
with the hosts systems' 10443, and the URL I use to access z/OSMF is
https://localhost:10443/zosmf.
So I'm at a bit of a loss in understanding why the connection should be
refused.

Regards
Sean


On Fri, 5 Jun 2020 at 04:08, Michael Babcock  wrote:

> Oh and beware, just because the Verify Feature Bits job (and a couple of
> others) gets a zero condition code doesn’t mean it executed successfully.
> You have to check STDERR and STDOUT tabs.  Mine always gets a syntax
> error.
>
> On Thu, Jun 4, 2020 at 10:05 AM Sean Gleann  wrote:
>
> > It's been really quite a troublesome effort for me, Michael, but I guess
> > it's true to say that most of the problems are down to my rudimentary
> > knowledge of TCPIP and networking in general.
> > For various reasons, I have to use a tunnelled connection through to the
> > z/OS guest, and that makes things a bit more interesting.
> > The 'Getting Started' redbook (SG24-8457-00) has been my sole point of
> > reference all the way through, and yeah, it's OK - up to point. it
> doesn't
> > cover the tunnelling complication, naturally, and there are some very
> poor
> > typos to take into account.
> > As for the Workload Provisioning process in z/OSMF - after you've
> specified
> > a bunch of parameters, it's just a JCL generator/job submitter/checker
> with
> > a couple of z/OSMF-specific bits thrown in.
> > During the initial parameter specification phase I had considerable
> > difficulty at the point of specifying the RSA key, but eventually got it
> > right.
> > Step 3.2 in the process - where some sort of version information is
> looked
> > for - has always failed for me. I've never been able to make it work as
> > expected and have had to force it to a 'complete' state by clicking the
> > 'Finish' button.
> >
> > I tried to adapt the process detailed in the redbook to suit our security
> > set-up, but the result never worked. In the end, I followed the procedure
> > to the letter, and created the ZCXxxx users and groups in RACF as
> > specified.
> > Result - I've finally got a working container that I can log in to. The
> > next step according to the redbook is to download an image from
> > hub.docker.com, but when I try the specified command - 'docker pull
> nginx'
> > - the container tries to go to registry-1.docker/.io/v2 - which isn't
> > specified anywhere in the parameter files created by z/OSMF  - and it
> times
> > out.
> > I've added suitable mods to \etc\hosts, \etc\ipnodes and to TCPIP.HOSTS,
> > messed around with DNS specifications and I've commented out the IPSEC
> > statements in the TCPIP PROFILE parameters (thank gawd for sandbox
> > systems!). Nothing along those lines has altered the situation.
> > Now, I'm waiting for our company networking guys to suggest other things
> to
> > try.
> >
> > Good luck with your efforts, Michael.
> > I hope you have a smoother ride than I have had so far.
> >
> > Sean
> >
> > On Thu, 4 Jun 2020 at 15:32, Michael Babcock 
> > wrote:
> >
> > > Sean,
> > >
> > > I’m just going through the provisioning process now.  Any gotchas that
> > you
> > > care to share?
> > >
> > > On Thu, Jun 4, 2020 at 5:30 AM Sean Gleann 
> > wrote:
> > >
> > > > Thanks, Gadi.
> > > > Yes, there are GLZ messages associated wi

Re: AZD messages?

[Sean Gleann]

It's been really quite a troublesome effort for me, Michael, but I guess
it's true to say that most of the problems are down to my rudimentary
knowledge of TCPIP and networking in general.
For various reasons, I have to use a tunnelled connection through to the
z/OS guest, and that makes things a bit more interesting.
The 'Getting Started' redbook (SG24-8457-00) has been my sole point of
reference all the way through, and yeah, it's OK - up to point. it doesn't
cover the tunnelling complication, naturally, and there are some very poor
typos to take into account.
As for the Workload Provisioning process in z/OSMF - after you've specified
a bunch of parameters, it's just a JCL generator/job submitter/checker with
a couple of z/OSMF-specific bits thrown in.
During the initial parameter specification phase I had considerable
difficulty at the point of specifying the RSA key, but eventually got it
right.
Step 3.2 in the process - where some sort of version information is looked
for - has always failed for me. I've never been able to make it work as
expected and have had to force it to a 'complete' state by clicking the
'Finish' button.

I tried to adapt the process detailed in the redbook to suit our security
set-up, but the result never worked. In the end, I followed the procedure
to the letter, and created the ZCXxxx users and groups in RACF as specified.
Result - I've finally got a working container that I can log in to. The
next step according to the redbook is to download an image from
hub.docker.com, but when I try the specified command - 'docker pull nginx'
- the container tries to go to registry-1.docker/.io/v2 - which isn't
specified anywhere in the parameter files created by z/OSMF  - and it times
out.
I've added suitable mods to \etc\hosts, \etc\ipnodes and to TCPIP.HOSTS,
messed around with DNS specifications and I've commented out the IPSEC
statements in the TCPIP PROFILE parameters (thank gawd for sandbox
systems!). Nothing along those lines has altered the situation.
Now, I'm waiting for our company networking guys to suggest other things to
try.

Good luck with your efforts, Michael.
I hope you have a smoother ride than I have had so far.

Sean

On Thu, 4 Jun 2020 at 15:32, Michael Babcock  wrote:

> Sean,
>
> I’m just going through the provisioning process now.  Any gotchas that you
> care to share?
>
> On Thu, Jun 4, 2020 at 5:30 AM Sean Gleann  wrote:
>
> > Thanks, Gadi.
> > Yes, there are GLZ messages associated with these AZDs, but all they do
> is
> > identify the stored failure data.
> >
> > It's all somewhat moot now. I tried to /P the container, and got told the
> > task was non-cancellable.
> > Eventually I resorted to a FORCE ARM to get rid of it.
> > Restarted the task and now it's running perfectly! No errors or warnings,
> > and I'm logged in, ready to start working with my first container.
> >
> > Sean
> >
> > On Thu, 4 Jun 2020 at 11:12, Gadi Ben-Avi  wrote:
> >
> > > I found this:
> > >
> > >
> >
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.izso100/izso100_diagnosisservice.htm
> > >
> > > It looks like the real information is in GLZ messages.
> > >
> > > I don't have z/OS v2.4 running, so I can't really check.
> > >
> > > Gadi
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> Behalf
> > > Of Sean Gleann
> > > Sent: Thursday, June 4, 2020 12:53 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: AZD messages?
> > >
> > > Can anyone point me at documentation for AZD... messages coming out of
> a
> > > zcx container, please?
> > >
> > > I'm getting:
> > > AZDN0004E Failure  configuring IPv4 address and AZDP0001E
> Unexpected
> > > error 5 configuring data disks
> > >
> > > but various attempts at searching for these produce 'nothing found'
> > > responses.
> > >
> > > Regards
> > > Sean
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email
> > > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> > > Email secured by Check Point
> > >
> > > --
> > > 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 / arc

Re: AZD messages?

[Sean Gleann]

Thanks, Gadi.
Yes, there are GLZ messages associated with these AZDs, but all they do is
identify the stored failure data.

It's all somewhat moot now. I tried to /P the container, and got told the
task was non-cancellable.
Eventually I resorted to a FORCE ARM to get rid of it.
Restarted the task and now it's running perfectly! No errors or warnings,
and I'm logged in, ready to start working with my first container.

Sean

On Thu, 4 Jun 2020 at 11:12, Gadi Ben-Avi  wrote:

> I found this:
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.izso100/izso100_diagnosisservice.htm
>
> It looks like the real information is in GLZ messages.
>
> I don't have z/OS v2.4 running, so I can't really check.
>
> Gadi
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Sean Gleann
> Sent: Thursday, June 4, 2020 12:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AZD messages?
>
> Can anyone point me at documentation for AZD... messages coming out of a
> zcx container, please?
>
> I'm getting:
> AZDN0004E Failure  configuring IPv4 address and AZDP0001E Unexpected
> error 5 configuring data disks
>
> but various attempts at searching for these produce 'nothing found'
> responses.
>
> Regards
> Sean
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> Email secured by Check Point
>
> --
> 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

AZD messages?

[Sean Gleann]

Can anyone point me at documentation for AZD... messages coming out of a
zcx container, please?

I'm getting:
AZDN0004E Failure  configuring IPv4 address
and
AZDP0001E Unexpected error 5 configuring data disks

but various attempts at searching for these produce 'nothing found'
responses.

Regards
Sean

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

Re: Request for help with CBT961

[Sean Gleann]

Lionel: I just tried exactly the same test as you describe, but Nope - I
get the results I previously got.
It must be down to my environment somehow.
I shall work on making  formal change to the config table and come back on
this later

Thanks for all your help

Regards
Sean


On Tue, 28 Apr 2020 at 14:23, Lionel B Dyck  wrote:

> I copied your JCL statement into my library, changed it to lowercase, and
> then used JU which did just that one line. I then reset that line to
> lowercase and used JU3 and all 3 lines were uppercased.
>
> The issue may be with the ispf configuration table or the table.
> Difficult to know.
>
> I have tested this in the past with my own SYSEXEC, my own ISPTLIB for the
> table and my own ISPLLIB for the ISPF Configuration (and I'm still running
> that way as I do this for testing.
>
>
> Lionel B. Dyck <
> Website: https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Sean Gleann
> Sent: Tuesday, April 28, 2020 8:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Request for help with CBT961
>
> Problem with he JU command w.r.t. multil-ine JCL statements?
>
> I'm not sure whether I've found a bug or if my expectations exceed the
> capability of Yves' code.
>
> I haven't yet updated the ISPF Configuration Table. At this stage I want
> to keep the new facilities 'under test', so I followed Paul Beesley's
> suggestion earlier in this thread.
>
> Example: I have a DD statement split over three lines:
>
> //PDBOUT   DD   DSN=TESTFILE.NAME,
> //  DISP=(NEW,CATLG,DELETE),SPACE=(TRK,(3000,150)),
> //  DSORG=PS,RECFM=FS,BLKSIZE=27648,LRECL=27648
>
> I deliberately change the text to lower case with 'LC' commands:
>
> //pdbout   dd   dsn=testfile.name,
> //  disp=(new,catlg,delete),space=(trk,(3000,150)),
> //  dsorg=ps,recfm=fs,blksize=27648,lrecl=27648
>
> Then I use JU commands, hoping to change the text back to upper-case:
>
> //PDBOUT   DD   DSN=TESTFILE.NAME,
> //  disp=(new,catlg,delete),space=(trk,(3000,150)),
> //  dsorg=ps,recfm=fs,blksize=27648,lrecl=27648
>
> Lines beginning '//' aren't being converted...
> I've tried again and used JUU...JUU, and with JU# - same result
>
> Regards
> Sean
>
>
> On Tue, 28 Apr 2020 at 11:45, Lionel B Dyck  wrote:
>
> > Glad you got it working - Yves did a FANTASTIC job creating this tool
> > that greatly improves ISPF Edit.
> >
> >
> > Lionel B. Dyck <
> > Website: https://www.lbdsoftware.com
> >
> > "Worry more about your character than your reputation.  Character is
> > what you are, reputation merely what others think you are." - John
> > Wooden
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Sean Gleann
> > Sent: Tuesday, April 28, 2020 5:08 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Request for help with CBT961
> >
> > I just noticed that one myself, Lionel. No, i didn't. (Got mixed up as
> > to which z/OS version I was using. Doh!) Thanks anyway Sean
> >
> > On Tue, 28 Apr 2020 at 11:05, Joe Monk  wrote:
> >
> > > Maybe this will help:
> > >
> > > //***FILE 961 is from Yves Colliard and contains a collection of*
> > > FILE 961
> > > //*   ISPF commands which can be added to your session. *
> > > FILE 961
> > > //* *
> > > FILE 961
> > > //* YCLMAC - A collection of user line commands for use in  *
> > > FILE 961
> > > //*  ISPF Edit and View *
> > > FILE 961
> > > //* *
> > > FILE 961
> > > //* by YCOS Yves Colliard Software - www.ycos.de*
> > > FILE 961
> > > //* and many others *
> > > FILE 961
> > > //* *
> > > FILE 961
> > > //* Installation:   *
> > > FILE 961
> > > //* *
> > > FILE 961
> > > //* 1. Copy YCLMACTB into ISPTLIB library   *
> > > FILE 961
> > > //* 2. Copy REXX others into SYS

Re: Request for help with CBT961

[Sean Gleann]

Problem with he JU command w.r.t. multil-ine JCL statements?

I'm not sure whether I've found a bug or if my expectations exceed the
capability of Yves' code.

I haven't yet updated the ISPF Configuration Table. At this stage I want to
keep the new facilities 'under test', so I followed Paul Beesley's
suggestion earlier in this thread.

Example: I have a DD statement split over three lines:

//PDBOUT   DD   DSN=TESTFILE.NAME,
//  DISP=(NEW,CATLG,DELETE),SPACE=(TRK,(3000,150)),
//  DSORG=PS,RECFM=FS,BLKSIZE=27648,LRECL=27648

I deliberately change the text to lower case with 'LC' commands:

//pdbout   dd   dsn=testfile.name,
//  disp=(new,catlg,delete),space=(trk,(3000,150)),
//  dsorg=ps,recfm=fs,blksize=27648,lrecl=27648

Then I use JU commands, hoping to change the text back to upper-case:

//PDBOUT   DD   DSN=TESTFILE.NAME,
//  disp=(new,catlg,delete),space=(trk,(3000,150)),
//  dsorg=ps,recfm=fs,blksize=27648,lrecl=27648

Lines beginning '//' aren't being converted...
I've tried again and used JUU...JUU, and with JU# - same result

Regards
Sean


On Tue, 28 Apr 2020 at 11:45, Lionel B Dyck  wrote:

> Glad you got it working - Yves did a FANTASTIC job creating this tool that
> greatly improves ISPF Edit.
>
>
> Lionel B. Dyck <
> Website: https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Sean Gleann
> Sent: Tuesday, April 28, 2020 5:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Request for help with CBT961
>
> I just noticed that one myself, Lionel. No, i didn't. (Got mixed up as to
> which z/OS version I was using. Doh!) Thanks anyway Sean
>
> On Tue, 28 Apr 2020 at 11:05, Joe Monk  wrote:
>
> > Maybe this will help:
> >
> > //***FILE 961 is from Yves Colliard and contains a collection of*
> > FILE 961
> > //*   ISPF commands which can be added to your session. *
> > FILE 961
> > //* *
> > FILE 961
> > //* YCLMAC - A collection of user line commands for use in  *
> > FILE 961
> > //*  ISPF Edit and View *
> > FILE 961
> > //* *
> > FILE 961
> > //* by YCOS Yves Colliard Software - www.ycos.de*
> > FILE 961
> > //* and many others *
> > FILE 961
> > //* *
> > FILE 961
> > //* Installation:   *
> > FILE 961
> > //* *
> > FILE 961
> > //* 1. Copy YCLMACTB into ISPTLIB library   *
> > FILE 961
> > //* 2. Copy REXX others into SYSEXEC or SYSPROC library *
> > FILE 961
> > //* 3. Update ISPF site customization table (ISPFC) (z/OS 2.2)  *
> > FILE 961
> > //*GLOBAL_LINE_COMMAND_TABLE = YCLMACTB *
> > FILE 961
> > //* 4. If using (E)JES instead of SDSF change the LMACJES2/3*
> > FILE 961
> > //*members from sdsf to ejes*
> > FILE 961
> > //* *
> > FILE 961
> > //* Members of this dataset:*
> > FILE 961
> > //* *
> > FILE 961
> > //*$$$DOC   This member that you are reading*
> > FILE 961
> > //*$$$HELP  A copy of the HELP information  *
> > FILE 961
> > //*$$$HELPS A short reference "card" of commands*
> > FILE 961
> > //* *
> > FILE 961
> > //* Rexx to be added to SYSEXEC/SYSPROC *
> > FILE 961
> > //*YCLMACDS REXX to extract DSN from records*
> > FILE 961
> > //*YCLMACHG Summary of Changes  *
> > FILE 961
> > //*YCLMACLM REXX to get messages*
> > FILE 961
> > //*YCLMACNS REXX to support split screen functions  *
> > FILE 961
> > //*YCLMACRX REXX to process new line commands 

Re: Request for help with CBT961

[Sean Gleann]

 for use with EX *
> FILE 961
> //*LMACUSS  Sample OMVS commands for use with EX*
> FILE 961
> //*LMACING  Sample System Automation cmds use   *
> FILE 961
> //* with EX *
> FILE 961
> //*LMACISPF Sample ISPF commands use with EX*
> FILE 961
> //* *
> FILE 961
> //* Sample coding for own application   *
> FILE 961
> //*YLM01Sample application using own line   *
> FILE 961
> //* commands*
> FILE 961
> //*YLM02Sample application using own line   *
> FILE 961
> //* commands*
> FILE 961
> //* *
> FILE 961
> //* Addition of user/local commands:*
> FILE 961
> //* *
> FILE 961
> //*1. Update YCLMACT with the name of the new command   *
> FILE 961
> //*   - Update at the bottom in the User Command section*
> FILE 961
> //*   - Follow the coding examples in YCLMACT   *
> FILE 961
> //*2. Run the REXX YCLMACT to replace the line command  *
> FILE 961
> //*   table YCLMACTB*
> FILE 961
> //*3. Copy YCLMACTB into the ISPTLIB library*
> FILE 961
> //*    4. Create a REXX Exec Y$xxx  *
> FILE 961
> //*   - where xxx is the 1-6 character name of the new  *
> FILE 961
> //* command *
> FILE 961
> //*5. Update YCLMAHLU to document the new command   *
> FILE 961
> //* *
> FILE 961
>
> Joe
>
> On Tue, Apr 28, 2020 at 4:58 AM Sean Gleann  wrote:
>
> > Can anyone help me with installing/using the ISPF editor extensions
> > provided in CBT961, please?
> >
> > CBT961 came to my notice when reading through another thread here, and I
> > thought it might come in handy.
> > I've downloaded and RECVd the install package, then modified and used
> > the £££INST skeleton JCL to copy the supplied members into the SYSEXEC
> and
> > ISPTLIB liraries specified in the relevant concatenations in my TSO logon
> > proc.
> > Logged off and on again, and tried to make use of the new commands in an
> > ISPF edit ...
> > Result: 'Command not recognised' in every case.
> > What (almost certainly very basic) step have I missed out here?
> > It's not a RACF thing. It's just as if I hadn't done anything at all.
> >
> > Hopefully,
> > Sean Gleann
> >
> > --
> > 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

Request for help with CBT961

[Sean Gleann]

Can anyone help me with installing/using the ISPF editor extensions
provided in CBT961, please?

CBT961 came to my notice when reading through another thread here, and I
thought it might come in handy.
I've downloaded and RECVd the install package, then modified and used
the £££INST skeleton JCL to copy the supplied members into the SYSEXEC and
ISPTLIB liraries specified in the relevant concatenations in my TSO logon
proc.
Logged off and on again, and tried to make use of the new commands in an
ISPF edit ...
Result: 'Command not recognised' in every case.
What (almost certainly very basic) step have I missed out here?
It's not a RACF thing. It's just as if I hadn't done anything at all.

Hopefully,
Sean Gleann

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

Re: CAS9

[Sean Gleann]

I was going to chip in earlier with my knowledge of VTAMAPPL, but got
beaten to it.
I've been using VTAMAPPL since working with multiple z/PDT systems, and
then copying the module across to z/OS LPARs as required.
I've got no idea where the source for VTAMAPPL is, nor of any documentation
for it - adaptation of the examples available on z/PDT were sufficient for
my purposes.
It was only this thread  that prompted me take a second look at the
VTAMAPPL module, only to see a copyright notice 'eyecatcher'.
That was enough for TPTB here to require removal of VTAMAPPL, and so I've
changed over to using the COMMAND program that has been mentioned.
Cutover took about half a day on my sandbox system - most of that time was
taken up with reading the available doc, etc.

One plus point for COMMAND over VTAMAPPL is that COMMAND can respond to
console messages. With VTAMAPPL, I had created REXX execs to handle
starting and stopping of my IMS region. Those execs are now redundant, and
all the commands that are issued are held in single streams for system
start and stop.

Regards
Sean

On Wed, 11 Mar 2020 at 04:08, Brian Westerman 
wrote:

> While our SyzCMD/z product it isn't free, it is very inexpensive, and it
> has all of the capabilities of the products mentions as well as MANY more
> features.
>
> http://www.syzygyinc.com/SyzCMDz.htm
>
> Brian Westerman
>
> --
> 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: Manuals for CA-VOLLIE?

[Sean Gleann]

"...It is 1000% better than the IBM VSE offering (name escapes me)"
It's 'ICCF' - but I really had to hunt for *that* particular brain cell.
I remember getting myself into trouble with my manager when recovering from
forgetting my password.
I dumped the first track of the ICCF VSAM(?), and there were all the
passwords, in plain text!
Hopefully that was changed in later days.

Regards
Sean

On Tue, 4 Feb 2020 at 02:09, Wayne Bickerdike  wrote:

> That's a blast from the past.
> It does run as a CICS transaction (Normally OLLE).
>
> It is 1000% better than the IBM VSE offering (name escapes me).
>
> In architecture it's not unlike ROSCOE, runs very lean and mean. All
> the members are contained within a single VSAM cluster which is
> formatted and then has 3 char lib prefixes and 8 char names similar to
> a PDS. eg JCL.MASTJOB1.
>
> It also has a crude form of security, defined in a macro assembler
> module. This determines what you can see and do. A very naughty
> programmer substituted his own version and when we found out, I
> substituted yet another module that blasted ***violation*** on the
> console. The guy in question (Kevin Parker where are you now?) crapped
> his pants when he realised he'd been rumbled. Had an entertaining
> dressing down meeting with him.
>
> From memory, I belive you use the "l" command (list) to bring up a
> member in an editor panel.
>
> It has a submit command (I think sub?) and has access to the Power
> spool to fetch output.
>
> It's been 30 years since I last saw Vollie :)
>
> On 2/4/20, Bernd Oppolzer  wrote:
> > great, thank you, I will have to ask my customer, if we can have access
> > to this site.
> > Thanks, kind regards
> >
> > Bernd
> >
> >
> > Am 03.02.2020 um 20:51 schrieb Frank Swarbrick:
> >> I don't have a Broadcom logon, but did you try this page?
> >>
> https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-miscellaneous/legacy_bookshelves_and_pdfs/bookshelves_and_pdfs/bookshelves/ca-vollie-for-z-vse.html
> >>
> >> 
> >> From: IBM Mainframe Discussion List  on
> behalf
> >> of Bernd Oppolzer 
> >> Sent: Monday, February 3, 2020 11:25 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU 
> >> Subject: Manuals for CA-VOLLIE?
> >>
> >> In my new project assignment, I have to use a tool called VOLLIE (from
> >> CA), which is used to modify (edit)
> >> VSE libraries and prepare compile and test jobs for VSE and COBOL-CICS
> >> programs etc.
> >>
> >> No VM in this installation. VOLLIE seems to be a CICS transaction.
> >>
> >> Is there a manual for CA-VOLLIE, which can be shared, for example PDF
> >> format?
> >> No match when using the well-known search engines.
> >>
> >> Thanks and regards
> >>
> >> Bernd
> >>
> >> --
> >> 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
> > --
> >
> > Oppolzer-Informatik
> > Dipl. Inf. Bernd Oppolzer
> > Bärenhofstraße 23
> > 70771 Leinfelden-Echterdingen
> > —
> > Tel.: +49 711 7949591
> > priv.: +49 711 7949590
> > mobil: +49 151 75005359
> > eMail: bernd.oppol...@t-online.de 
> > Web: http://bernd-oppolzer.de/job.htm
> > —
> > Für Umsatzsteuerzwecke:
> > SteuerNr.: 97 076 / 29921
> > USt-ID-Nr.: DE 147 700 393
> > —
> > Oppolzer-Informatik 1983 - 2019
> > 36years of experience in computer science**
> >
> >
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Wayne V. Bickerdike
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

A little pre-Christmas diversion...

[Sean Gleann]

Something I noticed on the BBC web site this morning...
https://www.bbc.co.uk/news/av/uk-50840818/i-was-a-teenage-code-breaker-at-bletchley-park

My main take-away from it was "92 years old and still as bright as a
button!" I hope I last that well...".

Merry Christmas, all
Sean

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

Re: Zfs from 1 LPAR to another

[Sean Gleann]

I'd probably be inclined to use a TERSEd DFDSS dump, too - but that's just
because I don't implicitly 'trust' (read: 'understand') UNIXy things.

One such 'thing' I was shown was:
tar -cf -  ¦ ssh  -l  "cd  ; tar -vxf -"
Apparently this means something like: "create a tar ball of  on
stdout then pipe it through to stdin for input to an un-tar command, after
logging on to logging on to  and cd-ing to "
It worked without a problem the only time I used it but, as I say, I was
too darn scared of using it again. Too many possible ways of screwing up,
as far as I was concerned.

Sean

On Wed, 6 Nov 2019 at 15:45, David Spiegel  wrote:

> Hi Itschak AMV"SH,
> Why did you use IDTF format instead of TRS?
>
> Regards,
> David
>
> On 2019-11-06 10:22, ITschak Mugzach wrote:
> > Kees,
> >
> > Dfdss in general is not ftp freindly. When we faced that in a large data
> > movement project, we used xmit to convert the file format to xmt on one
> > side and rexyeive it on the other side.
> >
> > ITschak
> >
> >
> >
> > בתאריך יום ד׳, 6 בנוב׳ 2019, 17:18, מאת Vernooij, Kees (ITOP NM) - KLM ‏<
> > kees.verno...@klm.com>:
> >
> >> So do we.
> >>
> >> And I wonder what the actual problem is? If the DFDSS dump dataset has
> >> such a special (internal) format, that FTP cannot always handle it
> >> correctly, why can AMATERSE do this without problems?
> >>
> >> If it FTP only, what is the special problem for FTP? What other dataset
> >> formats are a problem for FTP?
> >>
> >> Questions, Fear, Uncertainty and Doubt...
> >>
> >> Kees.
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> >> Behalf Of Lizette Koehler
> >> Sent: 06 November 2019 16:11
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Zfs from 1 LPAR to another
> >>
> >> I have always FTP a DFDSS dump of "things"  - What I was told to do long
> >> ago and far away was to include BLKSIZE=32760 on the dump file in DFDSS.
> >>
> >> This has never caused an issue (DFDSS ignores the Blksize).  And my
> >> Transfer have (knock wood) not failed.  And I have always been able to
> >> restore from the DFDSS dump.
> >>
> >>
> >> Lizette
> >>
> >>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List  On
> >>> Behalf Of Vernooij, Kees (ITOP NM) - KLM
> >>> Sent: Wednesday, November 06, 2019 8:02 AM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: Zfs from 1 LPAR to another
> >>>
> >>> Can you point to where that is documented?
> >>> We FTP a lot b.m.o. DFDSS between Sysplexes.
> >>>
> >>> Kees.
> >>>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> >>> On Behalf Of Tom Conley
> >>> Sent: 06 November 2019 15:46
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: Zfs from 1 LPAR to another
> >>>
> >>> On 11/5/2019 6:54 PM, Jousma, David wrote:
>  Terse, dont terse, your call.  I have 100% reliability as long as
>  the
> >>> destination disk dataset for the ftp is newly created.  If the
> >>> destination dataset already exists, then yes, there have been problems.
>  As you mention there are some specific options on the transfer to
>  specify,
> >>> and as long as you do, it will work fine.
>  Sending the dump file outside the company, probably not bad idea to
>  terse
> >>> since we are all familiar with it.
>  
>  __
>  ___
> 
>  Dave Jousma
> 
>  AVP | Manager, Systems Engineering
>  Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
>  Rapids, MI 49546
> 
>  616.653.8429  |  fax: 616.653.2717
>  
>  From: Tom Conley 
>  Sent: Tuesday, November 5, 2019 5:17 PM
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Subject: Re: Zfs from 1 LPAR to another
> 
> 
>  **CAUTION EXTERNAL EMAIL**
> 
>  **DO NOT open attachments or click on links from unknown senders or
>  unexpected emails**
> 
>  On 11/5/2019 3:11 PM, Wayne Bickerdike wrote:
> > I always terse the dump file too. Had issues with Restore if the
> > file wasn't  tersed.
> >
> > On Wed, Nov 6, 2019, 03:53 Pierre Fichaud 
> wrote:
> >
> >> Dave,
> >>I'll do that. The files are not big.
> >>They can be sent as ZIP files.
> >> Thanks, Pierre
> >>
> >> --
> >> --
> >> -- For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO
> >> IBM-MAIN
> >>
> > ---
> > --
> > - For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO
> > IBM-MAIN
> >
>  Wayne 

Re: Tracing RACF?

[Sean Gleann]

Problem solved - Many Thanks to all who responded.

Mark, David - My initial dismay at how file protection is handled in RACF
turned out to be unfounded (of course!).
I was primarily thinking about the number of user or group profiles I'd
have to define in order to adequately protect my system.
It turned out to be mercifully few... on my sandbox system, at least.

I'm going to SETROPTS PROTECTALL(WARNING) on the production system later
today
Doubtless there will be many screams regarding '...all these new
messages!', but the bulk of them get solved fairly quickly

Regards
Sean

On Sun, 3 Nov 2019 at 20:29, scott Ford  wrote:

> The ADDSD is a profile if the dataset or HLQ isn’t found it will fail.
>
> On Sun, Nov 3, 2019 at 2:25 AM Jon Perryman  wrote:
>
> >
> >
> > On Wednesday, October 30, 2019, 08:52:22 AM PDT, Sean Gleann <
> > sean.gle...@gmail.com> wrote:
> >
> > > If I try to ADDSD 'ABC.DEF' UACC(NONE), I get "ICH09006I USER OR GROUP
> >
> > > ABC  NOT DEFINED TO RACF"
> >
> >
> > I believe the error message is complaining about the OWNER which is
> > defaulting to ABC. Specify OWNER(xxx) where xxx is a valid userid or
> group.
> > Alternatively, there is a RACF option that will set the owner to the user
> > who creates the profile.
> >
> > Jon.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
> --
> 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: Tracing RACF?

[Sean Gleann]

I started this thread back in September, and got a lot of useful advice
from responders for which a heartfelt 'Thank You'.

Now I'm at the point of putting that advice in to action and I'm afraid
I've hit an apparent problem (in my eyes, at least).
I'm also using a RedBook "ABCs of z/OS System Programming Volume 6"
(SG24-6986), page 51ff as a source of guidance.
Per that book, the first thing I need to do to protect a specific file is
to use an 'ADDSD' command to define the file name.
If I try to ADDSD 'ABC.DEF' UACC(NONE), I get "ICH09006I USER OR GROUP
ABC  NOT DEFINED TO RACF"
Well - that's right. High-level qualifier 'ABC' is not a user-id, nor is it
group name and it is not intended to be, either.
'ABC' is used to identify files that are used by multiple groups of users -
there is no single 'owner' as such.

By implication, I've got to create a user (or group) named ABC in order to
proceed.
Extending that implication, I've got to create users (or groups) for every
single HLQ currently in use on my system(s).

That can't be right, surely. I've got to be missing something somewhere.
Can anyone shine a light on this, please?
Regards
Sean

On Mon, 7 Oct 2019 at 13:53, Sean Gleann  wrote:

> "...The fact that SMS data sets must be catalogued..." was the missing bit
> for me.
> I've never before worked in a position where I was allowed to use non-SMS
> datasets, so the possibilities involved with such things was something I'd
> never even begun to consider.
>
> When this particular situation was 'discovered', my main worry was that
> all my SYS1... type datasets were equally at risk. I've since shown that
> not to be the case, but it's not due to RACF or SMS rules. All those
> datasets are on disks that are attached from VM in R/O mode. To alter
> anything in them requires the 'owning' VM to be started up, and - at this
> site - *that* requires management sanction.
>
> Thank you for all your help in this. As you've highlighted, I'm going to
> have to switch PROTECTALL on and then handle all the screams of dismay from
> developers.
>
>
> Regards
>
> Sean
>
> On Thu, 3 Oct 2019 at 15:30, retired mainframer 
> wrote:
>
>> To recap:
>>PROTECTALL is off.
>>No RACF profile protects the DSN in question.
>>The MCAT is protected by a profile.
>>An admin creates the non-SMS dataset TEST which gets catalogued in the
>> MCAT.
>>A non-admin deletes the dataset which results in an orphan catalog
>> entry.
>>You are surprised.
>>
>> Why?
>>The data set is completely unprotected.  The fact that it is on a
>> non-SMS volume or catalogued in the MCAT makes very little difference.
>> Under these conditions, ANY USER IS AUTHORIZED to edit the contents or
>> delete the dataset.  There are probably other actions available.  The user
>> may even be able to rename the data set to XTEST which would result in it
>> being no longer catalogued in addition to the orphan entry.  The user may
>> be able to rename the data set to DSN that gets catalogued in a UCAT which
>> would result in two catalog entries (a correct UCAT and an orphan MCAT).
>>If the admin had specified a STORCLAS when creating the dataset, it
>> would have been placed on an SMS volume.  I don't think anything would have
>> changed (except possibly for the rename).
>>If the admin had used a DSN that meets your ACS qualifications but is
>> still not protected by a profile, the previous paragraph would still apply
>>If the admin had used a DSN that is catalogued in a UCAT but is still
>> not protected by a profile, the data set is still completely unprotected
>> but now you will not be left with an orphan catalog entry.
>>If the admin had specified KEEP instead of CATLG, the dataset would
>> still be unprotected but there would not be an MCAT entry to be orphaned.
>>
>> The catalog structure has nothing to do with data set protection.  The
>> fact that SMS data sets must be catalogued would prevent your non-admin
>> from creating TEST in the first place but once it is created the barn door
>> is wide open.
>>
>> The fact that PROTECTALL is off and you have many unprotected data sets
>> is a major security hole.  Any unprotected data set is just a problem
>> waiting to bite you.
>>
>> > -Original Message-
>> > From: IBM Mainframe Discussion List  On
>> > Behalf Of Sean Gleann
>> > Sent: Thursday, October 03, 2019 5:17 AM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: Tracing RACF?
>> >
>> > You mean, did I actually specify a volser on the "Data Set List Utility"
>> > panel?
>

Re: Best way for a task to give up the CPU and let other tasks run?

[Sean Gleann]

Back in the days of IPS/ICS dispatching control, wasn't there something
that was referred to as the 'wheeler-dealer mechanism' & does it still
exist in some form in the WLM code?
>From memory:
1. New task gets created and is assigned a time-slice of 1msec, at a
priority of 32 (out of 64 - i.e  'half'), then placed on the dispatch queue
2. Task eventually shuffles to the top of the queue and starts running.
3. If the task voluntarily relinquishes control (due to some sort of SVC
call, etc) before the time slice expires, then the time slice duration gets
doubled and the priority is reduced by 50%.
4. Alternatively, if the time slice expires and the OS unilaterally wrests
control from the task, then the time slice duration gets halved and the
priority is bumped by 50%
5. Task is once more placed on the dispatch queue
6. etc...

I may have the actions of  (3) and (4) round the wrong way. I wouldn't be
at all surprised to be told I'm completely wrong. As I say, this is all
from a memory and I seem to have so few neurons left these days.

Sean

On Sun, 20 Oct 2019 at 14:02, Charles Mills  wrote:

> I just looked up "External Interruption" in the Principles. There are at
> least 9 possible causes.
>
> IIRC on the System 360 there was an eight-pin Molex connector available
> and a customer-provided box of some sort could trigger an external
> interrupt by pulling the appropriate pin to ground. See page 19 of
> http://www.bitsavers.org/pdf/ibm/360/systemSummary/GA22-6810-12_360sysSumJan74.pdf
> .
>
> IIRC MICR check sorters used this feature to generate their high-priority
> interrupts to the processor.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tom Brennan
> Sent: Saturday, October 19, 2019 7:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Best way for a task to give up the CPU and let other tasks
> run?
>
> Interesting, thanks!  So it generates an external interrupt.  I always
> thought that one was only for the external interrupt "key", but this
> page indicates CPU timer and some kind of CP-to-CP communication too:
>
>
> https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zconcepts/zconc_interrupts.htm
>
> Ok... now back to my weekend work, like changing the oil in my truck.
>
> --
> 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: [EXT] Re: zOS 2.4 migration guide

[Sean Gleann]

@Kurt - thank you for the qualification - "...but z/OS software will
continue to be serviced using PTFs and therefore using SMP/E".
I hadn't read or heard that until now. Its good to hear that that is the
case.

Sean

On Sat, 19 Oct 2019 at 00:49, Mark Zelden  wrote:

> z/OSMF can create an extract of the migration information (now called
> "upgrade" instead
> of "migration")  from the z/OSMF workflow (either z/OS 2.2 to z/OS 2.4 or
> z/OS 2.3
> to z/OS 2.4 - whichever one you import from GitHub or both).  It's in HTML
> format
> and quite readable with links to the different sections.
>
> While this may not be well known (it wasn't to me), there is also a link
> on GitHub along
> with the workflows to pre-exported migration information, which is in
> essence the migration
> manual.   It's super easy to miss, so read the "readme" carefully.
>
> Changing the subject to z/OSMF itself...
>
> Although you may not require z/OSMF to get the upgrade information, I
> still strongly
> suggest you bite the bullet and get z/OSMF up and running - as long as you
> are at
> z/OS 2.3.   Like it or not, you're going to need it somewhere in your
> installation
> in the near future.It is a helava lot easier in z/OS 2.3 with the
> PARMLIB member
> customization taking the place of things you had to do previously do via
> scripts
> and unix customization.
>
> However, by far the biggest pain has not gotten any easier - all the RACF
> setup.
> The sample jobs are nice and are "close" but the don't take everything
> into account.
> You need to understand your RACF environment fairly well.For example,
> if you don't
> have enhanced generic naming in effect in RACF, some things have to be
> changed slightly.
>
> And there are a lot of jobs to customize / run for the different plugins
> (I combined mine
> all into a single job for the RACF people to run).  I work with dozens of
> sysprogs and
> almost none of them understand anything about RACF admin nor their local
> environments,
> and the RACF admins hardly understand RACF admin these days for my
> clients, let alone
> anything about z/OS or z/OSMF, so you can see the challenge.  Lucky for
> me, I understand
> both.
>
> I never bit the bullet myself until this year under z/OS 2.3 and it was
> fairly painless
> to install in 7 sysplexes after the first one I did in a sandbox sysplex
> when I had all
> the RACF jobs built along with other required jobs (CIM zFS creation /
> customization,
> z/OSMF zFS creation).  Attending some of the z/OSMF user sessions at SHARE
> years
> ago made me really dread doing this prior to z/OS 2.3 across many different
> sysplxes, but with z/OS 2.3 copying some jobs to run and a parmlib member
> to another
> sysplex wasn't difficult.  Other than waiting for RACF admins to run the
> RACF jobs for me,
> I would have had z/OSMF running in a day or two on all but the first
> sysplex.
>
> Regards,
>
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> ITIL v3 Foundation Certified
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://search390.techtarget.com/ateExperts/
> --
> 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: [EXT] Re: zOS 2.4 migration guide

[Sean Gleann]

On our z14, z/OSMF takes some 60m+ EXCPs and 300 seconds of CPU time
(according to SDSF) before it can even be used...
(and anything that announces its availability with "...ready to run a
smarter planet" just makes me cringe.)

Carmen's remark about 'clear documentation' is very much on point. Like
him, I've been battling with the Configuration Assistant in order to create
a comms policy.
Every time I find any documentation that might help me, the examples given
show a z/OSMF UI that is different to mine and so the confusion starts
right at the point of logging on.
I suppose its because z/OSMF is still a very young bit of software and so
changes between versions are much more visible.

The idea that z/OSMF is intended to eventually replace SMP is quite
depressing, but - disclosure - I remember I had similar difficulty taking
SMP on board some aeons ago... using it is almost second nature now.

Sean

On Wed, 16 Oct 2019 at 17:57, Gibney, Dave  wrote:

> No zIIP here either. I guess, it doesn't matter. I expect 1 more
> migration, 2.1 to 2.2. Then mothballing
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Mark Charles
> > Sent: Wednesday, October 16, 2019 7:44 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [EXT] Re: zOS 2.4 migration guide
> >
> > I thought my situation was bad - it only takes 30 minutes at 100% CPU on
> my
> > test system to bring up z/OSMF.
> >
> > Does anyone run this on a production 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
>

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

Re: Tracing RACF?

[Sean Gleann]

"...The fact that SMS data sets must be catalogued..." was the missing bit
for me.
I've never before worked in a position where I was allowed to use non-SMS
datasets, so the possibilities involved with such things was something I'd
never even begun to consider.

When this particular situation was 'discovered', my main worry was that all
my SYS1... type datasets were equally at risk. I've since shown that not to
be the case, but it's not due to RACF or SMS rules. All those datasets are
on disks that are attached from VM in R/O mode. To alter anything in them
requires the 'owning' VM to be started up, and - at this site - *that*
requires management sanction.

Thank you for all your help in this. As you've highlighted, I'm going to
have to switch PROTECTALL on and then handle all the screams of dismay from
developers.


Regards

Sean

On Thu, 3 Oct 2019 at 15:30, retired mainframer 
wrote:

> To recap:
>PROTECTALL is off.
>No RACF profile protects the DSN in question.
>The MCAT is protected by a profile.
>An admin creates the non-SMS dataset TEST which gets catalogued in the
> MCAT.
>A non-admin deletes the dataset which results in an orphan catalog
> entry.
>You are surprised.
>
> Why?
>The data set is completely unprotected.  The fact that it is on a
> non-SMS volume or catalogued in the MCAT makes very little difference.
> Under these conditions, ANY USER IS AUTHORIZED to edit the contents or
> delete the dataset.  There are probably other actions available.  The user
> may even be able to rename the data set to XTEST which would result in it
> being no longer catalogued in addition to the orphan entry.  The user may
> be able to rename the data set to DSN that gets catalogued in a UCAT which
> would result in two catalog entries (a correct UCAT and an orphan MCAT).
>If the admin had specified a STORCLAS when creating the dataset, it
> would have been placed on an SMS volume.  I don't think anything would have
> changed (except possibly for the rename).
>If the admin had used a DSN that meets your ACS qualifications but is
> still not protected by a profile, the previous paragraph would still apply
>If the admin had used a DSN that is catalogued in a UCAT but is still
> not protected by a profile, the data set is still completely unprotected
> but now you will not be left with an orphan catalog entry.
>If the admin had specified KEEP instead of CATLG, the dataset would
> still be unprotected but there would not be an MCAT entry to be orphaned.
>
> The catalog structure has nothing to do with data set protection.  The
> fact that SMS data sets must be catalogued would prevent your non-admin
> from creating TEST in the first place but once it is created the barn door
> is wide open.
>
> The fact that PROTECTALL is off and you have many unprotected data sets is
> a major security hole.  Any unprotected data set is just a problem waiting
> to bite you.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Sean Gleann
> > Sent: Thursday, October 03, 2019 5:17 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Tracing RACF?
> >
> > You mean, did I actually specify a volser on the "Data Set List Utility"
> > panel?
> > In all cases up to now, the answer is 'No'.
> > But your query prompted a couple of experiments, all to no avail I'm
> afraid.
> > If I do specify the volser as well as the dsn, the only difference is
> that
> > the 'delete confirmation' panel that opens up has an extra option in it.
> > Instead of just "Set data set delete confirmation off", I also get
> > "Uncatalog data set upon deletion" - which is already selected with a
> '/'.
> > If I allow the deletion to go ahead with that selection, the only
> > difference is that I don't get to see a RACF violation on the MCAT. The
> > file still gets removed from the volume, leaving the orphaned MCAT entry
> > behind, just as before - but now I don't know about the uncatalog
> failure.
> > Regards
> > Sean
>
> --
> 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: Tracing RACF?

[Sean Gleann]

You mean, did I actually specify a volser on the "Data Set List Utility"
panel?
In all cases up to now, the answer is 'No'.
But your query prompted a couple of experiments, all to no avail I'm afraid.
If I do specify the volser as well as the dsn, the only difference is that
the 'delete confirmation' panel that opens up has an extra option in it.
Instead of just "Set data set delete confirmation off", I also get
"Uncatalog data set upon deletion" - which is already selected with a '/'.
If I allow the deletion to go ahead with that selection, the only
difference is that I don't get to see a RACF violation on the MCAT. The
file still gets removed from the volume, leaving the orphaned MCAT entry
behind, just as before - but now I don't know about the uncatalog failure.
Regards
Sean

On Wed, 2 Oct 2019 at 16:10, retired mainframer 
wrote:

> When the 3.4 list was requested, was a volser specified on the panel?
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Sean Gleann
> > Sent: Wednesday, October 02, 2019 12:45 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Tracing RACF?
> >
> > Answering 'retired mainframer's questions (and I'll probably be joining
> you
> > within the next year)
> >
> >  *What is the status of the SETROPTS PROTECTALL option?*
> >  A 'SETROPTS LIST' shows: 'PROTECT-ALL OPTION IS NOT IN EFFECT'. I
> > tried switching that with 'setropts protectall(warning)', but the sheer
> > volume of output that is generated swamps everything else.
> > *Is there any data set profile that covers the dataset?*
> >  No - filenames 'TEST' and 'TEST1' (the ones I have been using for
> > this) are not specifically identified anywhere in RACF
> > *Is there a global access checking table entry that covers the dataset?*
> >  Not sure exactly what this means, so I don't know how to check. But
> > see previous answer
> > *Does the non-admin user have the OPERATIONS attribute?*
> >  No.
> > *Is there a DASDVOL profile that covers the non-SMS volume in question?*
> >  Yes - the DBSYNC output shows 'redefine dasdvol v* uacc(none)',
> > followed by 'permit v* class(dasdvol) reset' (and 'v*' covers the volids
> > involved).  After that, there are no specific permissions defined
> > *And what command is the non-admin user issuing to perform the delete?*
> >  Just a simple 'D' against the file in an ISPF 3.4 list.
> >
> > Regards
> > Sean
> >
> >
> >
> >
> > On Tue, 1 Oct 2019 at 16:32, retired mainframer <
> retired-mainfra...@q.com>
> > wrote:
> >
> > > And what command is the non-admin user issuing to perform the delete?
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List  On
> > > > Behalf Of retired mainframer
> > > > Sent: Tuesday, October 01, 2019 5:37 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: Tracing RACF?
> > > >
> > > > What is the status of the SETROPTS PROTECTALL option?
> > > >
> > > > Is there any data set profile that covers the dataset?
> > > >
> > > > Is there a global access checking table entry that covers the
> dataset?
> > > >
> > > > Does the non-admin user have the OPERATIONS attribute?
> > > >
> > > > Is there a DASDVOL profile that covers the non-SMS volume in
> question?
> > > >
> > > > > -Original Message-
> > > > > From: IBM Mainframe Discussion List  On
> > > > > Behalf Of Sean Gleann
> > > > > Sent: Tuesday, October 01, 2019 3:10 AM
> > > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > > Subject: Re: Tracing RACF?
> > > > >
> > > > > Joao: yes, I have tried that, but it really doesn't give the
> > > information
> > > > > that I want - I can see the monitored user creating and deleting
> file,
> > > but
> > > > > I don't see anything about the RACF profiles that were used.
> > > > >
> > > > > Having said that, I have managed to move things along.
> > > > > The situation I now have is that an 'ordinary' user of my
> system(s) -
> > > as
> > > > > opposed to an 'administrator' user (there are three of us at this
> > > site) -
> > > > > cannot update the MCAT, so creating files that do not have the
> user's
> > > id as
> > > > > the first qualifier is now impossible.
> > >

Re: Tracing RACF?

[Sean Gleann]

Answering 'retired mainframer's questions (and I'll probably be joining you
within the next year)

 *What is the status of the SETROPTS PROTECTALL option?*
 A 'SETROPTS LIST' shows: 'PROTECT-ALL OPTION IS NOT IN EFFECT'. I
tried switching that with 'setropts protectall(warning)', but the sheer
volume of output that is generated swamps everything else.
*Is there any data set profile that covers the dataset?*
 No - filenames 'TEST' and 'TEST1' (the ones I have been using for
this) are not specifically identified anywhere in RACF
*Is there a global access checking table entry that covers the dataset?*
 Not sure exactly what this means, so I don't know how to check. But
see previous answer
*Does the non-admin user have the OPERATIONS attribute?*
 No.
*Is there a DASDVOL profile that covers the non-SMS volume in question?*
 Yes - the DBSYNC output shows 'redefine dasdvol v* uacc(none)',
followed by 'permit v* class(dasdvol) reset' (and 'v*' covers the volids
involved).  After that, there are no specific permissions defined
*And what command is the non-admin user issuing to perform the delete?*
 Just a simple 'D' against the file in an ISPF 3.4 list.

Regards
Sean




On Tue, 1 Oct 2019 at 16:32, retired mainframer 
wrote:

> And what command is the non-admin user issuing to perform the delete?
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of retired mainframer
> > Sent: Tuesday, October 01, 2019 5:37 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Tracing RACF?
> >
> > What is the status of the SETROPTS PROTECTALL option?
> >
> > Is there any data set profile that covers the dataset?
> >
> > Is there a global access checking table entry that covers the dataset?
> >
> > Does the non-admin user have the OPERATIONS attribute?
> >
> > Is there a DASDVOL profile that covers the non-SMS volume in question?
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Sean Gleann
> > > Sent: Tuesday, October 01, 2019 3:10 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Tracing RACF?
> > >
> > > Joao: yes, I have tried that, but it really doesn't give the
> information
> > > that I want - I can see the monitored user creating and deleting file,
> but
> > > I don't see anything about the RACF profiles that were used.
> > >
> > > Having said that, I have managed to move things along.
> > > The situation I now have is that an 'ordinary' user of my system(s) -
> as
> > > opposed to an 'administrator' user (there are three of us at this
> site) -
> > > cannot update the MCAT, so creating files that do not have the user's
> id as
> > > the first qualifier is now impossible.
> > > 'Administrators', on the other hand, can create and delete files at
> will.
> > > All of which is OK as far as I'm concerned.
> > >
> > > But (there's always a 'but'...)
> > > If an admin user creates a file named 'TEST' (for instance), the file
> is
> > > not covered by my SMS rules, and so it gets placed on one of the 5
> > > non-SMS-controlled disks that my PARMLIB(VATLSTxx) member identifies as
> > > being mounted 'PRIVATE'. I'd rather that didn't happen, but we're
> talking
> > > about an 'admin'-type user here, and they're supposed to know what
> they're
> > > doing, so things are OK up to this point.
> > > But now it appears that a non-admin user can delete the file, but not
> > > uncatalog it. The file disappears from the selected disk's VTOC, but
> the
> > > MCAT entry remains since the user is not allowed to update the MCAT. If
> > > this is allowed to continue I'll end up with an MCAT full of orphan
> entries.
> > >
> > > As I say, I've managed to move things along a bit, so my original query
> > > about 'Tracing RACF' is no longer an issue.
> > > Right now, I'm trying to improve my system's security so that users can
> > > create/delete their own files, but cannot do that to anyone else's,
> nor to
> > > files that are not covered by SMS.
> >
> > --
> > 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: Tracing RACF?

[Sean Gleann]

Joao: yes, I have tried that, but it really doesn't give the information
that I want - I can see the monitored user creating and deleting file, but
I don't see anything about the RACF profiles that were used.

Having said that, I have managed to move things along.
The situation I now have is that an 'ordinary' user of my system(s) - as
opposed to an 'administrator' user (there are three of us at this site) -
cannot update the MCAT, so creating files that do not have the user's id as
the first qualifier is now impossible.
'Administrators', on the other hand, can create and delete files at will.
All of which is OK as far as I'm concerned.

But (there's always a 'but'...)
If an admin user creates a file named 'TEST' (for instance), the file is
not covered by my SMS rules, and so it gets placed on one of the 5
non-SMS-controlled disks that my PARMLIB(VATLSTxx) member identifies as
being mounted 'PRIVATE'. I'd rather that didn't happen, but we're talking
about an 'admin'-type user here, and they're supposed to know what they're
doing, so things are OK up to this point.
But now it appears that a non-admin user can delete the file, but not
uncatalog it. The file disappears from the selected disk's VTOC, but the
MCAT entry remains since the user is not allowed to update the MCAT. If
this is allowed to continue I'll end up with an MCAT full of orphan entries.

As I say, I've managed to move things along a bit, so my original query
about 'Tracing RACF' is no longer an issue.
Right now, I'm trying to improve my system's security so that users can
create/delete their own files, but cannot do that to anyone else's, nor to
files that are not covered by SMS.

Regards
Sean



On Tue, 1 Oct 2019 at 04:24, Jon Perryman  wrote:

>  On Wednesday, September 25, 2019, 07:34:05 AM PDT, Allan Staller <
> allan.stal...@hcl.com> wrote:
>
>  > That is not considered a good practice in RACF circles. The best
> practice would be:
>
> > MCAT  - UACC(NONE) READ(*)  ALTER(sysprogs) (note: No update access
> except via sysprogs)
>
> Any system where the master catalog is not tightly controlled is at great
> risk and could become unusable. Any user can delete any alias in this
> environment. Potentially DB2, CICS, IMS or any number of important aliases
> could be lost.
>
> It's been many years since I've done anything with security. I believe at
> that time, IDCAMS DELETE NOSCRATCH for non-sms datasets was not controlled
> because it was only catalog services and no actual I/O was occurring. Has
> this problem been fixed? If not, then anyone can uncatalog sys1.linklib or
> sys1.lpalib thus causing the IPL to fail.
>
> Why aren't aliases created at the same time as the User? Additionally,
> data is out of control on your system. The RACF admin has not reviewed the
> security implication for aliases.
>
> Jon.
>
> --
> 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: Tracing RACF?

[Sean Gleann]

Thanks to all who have responded so far, and apologies for not responding
sooner (other work took precedence, unfortunately).

Trouble is - I'm no closer to a solution (but I haven't tried the GTF/IPCS
idea yet).

More on this if I have some news

Thanks again

Sean

On Fri, 27 Sep 2019 at 22:44, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 27 Sep 2019 00:13:25 -0500, Bruce Hewson wrote:
>
> >SMS will catalog in the MASTER CATALOG. It does override the
> >access rules. It really is important that ALIAS entries are defined
> >for any GROUP or USER created. If the USER has access to create
> >the dataset then SMS will catalog that dataset. I have plenty of
> >evidence to this.
>
> I knew I'd seen situations where it did not, so I did a quick search.
>
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.adru000/r2109.htm
>
> 
> SMS-managed data sets:
> Access to SMS-managed data sets gives you access to the user catalog
> for the data sets. However, for a RACF-protected master catalog, you
> also need UPDATE-access authority to add or delete an SMS-managed
> data set entry.
> 
>
> --
> Tom Marchant
>
> --
> 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

Tracing RACF?

[Sean Gleann]

Following a set of somewhat distressing events here, I discovered - the
hard way - that our master catalog was poorly protected, and so I now have
to fix it. The situation is that all users of the my system can create,
read, write, update, delete files that are cataloged in the MasterCat.

The original intention was that each user-id is defined in the MCat as an
alias that points to one of several User Catalogs, depending on the user's
'department' within the company. That way, user id 'X1' creates 'X1.TEST',
and it gets cataloged in a UCAT.

So far, so good.

Now I've found that if 'X1' creates file 'TEST1', it gets cataloged in the
MCAT. In order to prevent this, I've used existing information to act as a
model for
permit 'MASTERV.CATALOG' generic id(X1) access(read)
and specified that.

Now, if user X1 tries to create 'X1.TEST', the result is a RACF
authorisation failure.

Again, so far, so good

Taking the test a bit further though, I've now found that user X1 is
allowed to delete file 'TEST1' from the MCat!

My conclusion so far is that X1 must be getting the required access rights
from another user id/group/etc, but I can't see anything apposite in any
examination I do of the RACF rules (I use output from the DBSYNC Rexx
procedure for this).


So... Can anyone spot my error and suggest a different 'permit' command,
please?
Alternatively, I looked at the idea of tracing RACF activity on behalf of a
specific user with
SET TRACE(USERID(X1)) - but I can't see where generated output goes to nor
how to interrogate it. I *have* seen mention of using GTF for this purpose,
along with IPCS, but my experience with both those tools is so limited that
I didn't look much further in those references - skipped on past them,
looking for other possibilities but not finding any.

Any help gratefully appreciated
Sean

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

Re: Can you update WLM via a batch program?

[Sean Gleann]

I don't think so, Martin - but I'm not an XML expert by any means.
If I examine any of the members in the PDS that is used for input to
IWMINSTL, I don't see any of the  &  'tag' pairs that I'd expect
to see.
The names of the members are the same as for the results of saving an
existing WLM policy and using the 'ISPF tables' option (I'd forgotten that
was an option - so I must backtrack on my previous 'correction').
There *is* an option to save in XML format, but nothing in the IWMINSTL
member appears to refer to  using XML format as input.
Even so, to generate the input in either format requires an existing WLM
policy to be accessed via the ISPF panels.
It appears that creating a WLM policy from scratch in, well, 'plain
English', is still not possible, unfortunately.

Have a safe trip!

Sean

On Tue, 17 Sep 2019 at 11:00, Martin Packer 
wrote:

>
> XML perchance?
>
> If so there’s a lot one could do with that... :-)
>
> ... If the plane I was about to get on didn’t see me with my elbows (and
> knees) up round my ears I’d rustle up a proof of concept. :-)
>
> Cheers, Martin
>
> Sent from my iPad
>
> > On 17 Sep 2019, at 08:57, Sean Gleann  wrote:
> >
> > Correction - the input is *probably* not ISPF tables (having
> cross-checked
> > with other ISPTLIBs that I have available).
> > Nevertheless, they are 'encoded' - not straight text...
> >
> > Sean
> >
> >> On Tue, 17 Sep 2019 at 08:06, Sean Gleann 
> wrote:
> >>
> >> Having been in the same position as Jim, I asked practically the same
> >> question here, a couple of years back.
> >> Then, the basic answer was 'No', so I was highly pleased to see that
> some
> >> sort of progress had been made on this.
> >> I should have known better.
> >> IWMINSTL is a great starting point, but it's input is a series of ISPF
> (?)
> >> tables.
> >> How do you create those from scratch in the first place?
> >>
> >> Sean
> >>
> >>> On Mon, 16 Sep 2019 at 23:39, Salva Carrasco 
> wrote:
> >>>
> >>> Check IWMINSTL at SYS1.SAMPLIB.
> >>>
> >>> --
> >>> For IBM-MAIN subscribe / signoff / archive access instructions,
> >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>>
> >>
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Can you update WLM via a batch program?

[Sean Gleann]

Correction - the input is *probably* not ISPF tables (having cross-checked
with other ISPTLIBs that I have available).
Nevertheless, they are 'encoded' - not straight text...

Sean

On Tue, 17 Sep 2019 at 08:06, Sean Gleann  wrote:

> Having been in the same position as Jim, I asked practically the same
> question here, a couple of years back.
> Then, the basic answer was 'No', so I was highly pleased to see that some
> sort of progress had been made on this.
> I should have known better.
> IWMINSTL is a great starting point, but it's input is a series of ISPF(?)
> tables.
> How do you create those from scratch in the first place?
>
> Sean
>
> On Mon, 16 Sep 2019 at 23:39, Salva Carrasco  wrote:
>
>> Check IWMINSTL at SYS1.SAMPLIB.
>>
>> --
>> 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: Can you update WLM via a batch program?

[Sean Gleann]

Having been in the same position as Jim, I asked practically the same
question here, a couple of years back.
Then, the basic answer was 'No', so I was highly pleased to see that some
sort of progress had been made on this.
I should have known better.
IWMINSTL is a great starting point, but it's input is a series of ISPF(?)
tables.
How do you create those from scratch in the first place?

Sean

On Mon, 16 Sep 2019 at 23:39, Salva Carrasco  wrote:

> Check IWMINSTL at SYS1.SAMPLIB.
>
> --
> 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: Text to excel

[Sean Gleann]

Take special care with date values...
Over here in Leftpondia, date values are (normally) 'dd-mm-yy', or some
variation thereof. This can lead to some difficulties when sending data
from m/f to pc.
As Mike says, surround such values with quotes, thus forcing Excel to treat
them as text strings rather than numerics

Good Luck!
Sean

On Tue, 3 Sep 2019 at 07:31, Mike Schwab  wrote:

> Put in quotes and commas to create a CSV file is your best bet.  Then
> open in excel and save as an excel format.
> "field one   ","field two   ",123456789.12,"field three"
> Probably would be better to even put quotes around the number fields.
>
> On Tue, Sep 3, 2019 at 1:13 AM Peter  wrote:
> >
> > Hi Group
> >
> > I have been using txt2pdf for a long and I understand it also does
> building
> > CSV files which can be opened using Excel. Is there a way to convert a
> text
> > file into Excel automatically within mainframe as
> > .XLS prior sending to email server ?
> >
> > Peter
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: [EXTERNAL] Seeking help with DFSMSrmm

[Sean Gleann]

Erika, Simon
Thank you for coming back on this.

Up until the time of raising this thread, I was working with
RETENTIONMETHOD(EXPDT) specified, and getting the results I described.
Having sent my email, I moved on to RETENTIONMETHOD(VRSEL), but that didn't
help a lot - the EXPDT specified on the DD statements I was using had no
effect.
So I moved back to using EXPDT and UNCATALOG(N). My RETENTIONMETHOD
parameter is now:
RETENTIONMETHOD(EXPDT(CATLGDAYS(0) GDG(RETPD(0) WHILECATALOG(ON))
LASTREF(0) NOGDG(RETPD(0) WHILECATALOG(ON)) NOLASTREF RETAINBY(VOLUME)))
which gave results that were close to what I think should happen.

With this parameter in control, If I create a tape file with EXPDT=99000
specified then delete or uncatalog the file, and run the scratch
housekeeping job (EXPROC), then the tape that is used should be released,
to my way of thinking.
What actually happens is that the tape is tagged with an expiry date of
'today', sure, but it turns out there is also an expiry *time* to take in
to account. I don't know the exact method used to calculate this time
value, but it appears to be something like: 'current time plus 90 minutes,
rounded to the nearest hour'. So if I create a file at 9:00 and then delete
it, no amount of scratch processing will release the tape before 10:00. A
file created and deleted at 9:31 means that the associated tape volume
doesn't get released until 11:00.

*sigh* there's got to be a way around this. (going back to the manuals...)

Regards
Sean

On Tue, 30 Jul 2019 at 16:46, Erika Dawson  wrote:

> A good source of information on the different retention method options in
> RMM is the DFSMSrmm Primer:
> http://www.redbooks.ibm.com/abstracts/sg245983.html?Open ... this IBM
> Redbook provides a highlight of the different functions within RMM
> including the different retention methods that can be used ... retention
> through VRS policies RETENTIONMETHOD(VRSEL) and retention through
> expiration RETENTIONMETHOD(EXPDT).   After that you can look at Chapter 3
> Retention Methods in the following RMM manual ...
> https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc236873/$file/idarm00_v2r3.pdf
> for an overview of each.
>
> --
> 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

Seeking help with DFSMSrmm

[Sean Gleann]

I'm having considerable difficulty getting rmm to work on my system & I
wonder if anyone might be able to help.
The main problem is that I can't a seem to get it to retain tapes that have
unexpired files on them.
I've tried numerous combinations of settings in the EDGRMMxx parmlib
member, all to no avail.
I can get it to release tapes, yes, but it either leaves the associated
file names in the system catalog, or it unilaterally deletes them,
unexpired or not... which wouldn't make users very happy, should I ever let
this beast out of the sandbox.
If anyone has successfully implemented rmm on their system(s), perhaps you
can shed some light on this (almost certainly self-inflicted) problem.

Regards
Sean

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

Re: Using bpxbatch to compress an MVS dataset

[Sean Gleann]

Hi Donald
The URL in my original response to you appears to have been garbled by some
sort of 'protection' thingy.
I don't know how to work around that, but here's an attempt:
h t t p : / / g r o u p s . y a h o o . c o m / g r o u p / h e r c u l e s
- 3 9 0
just remove the spaces to get the correct link back.

Regards
Sean

On Mon, 1 Jul 2019 at 11:18, David Spiegel  wrote:

> Hi Seann,
> In which Group would I find TERSE.ZIP?
>
> Thanks and regards,
> David
>
> On 2019-07-01 06:05, Sean Gleann wrote:
> > Donald: From your initial query... "Terse is no good because Linux can’t
> > unterse it."
> > FWIW there is a TERSE application available from the old Hercules days
> that
> > includes implementations for Windows, DOS, MAC and Linux.
> > I tried it out on windows and found it worked tolerably well for handling
> > TERSEd data moving in both directions, but I can't speak for the Linux
> > implementation.
> > If you can login to yahoo groups
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroups.yahoo.com%2Fgroup%2Fhercules-390data=02%7C01%7C%7C90d8eaf26b1547e8f6d908d6fe0bd459%7C84df9e7fe9f640afb435%7C1%7C0%7C636975724126831910sdata=tYjKfYK%2FmO7rXFzgo8oU2oCX5dUF%2FHMQmukNZl90lKY%3Dreserved=0
> > and go to 'files', you should be able to find the TERSE.ZIP distribution
> > file.
> >
> > Regards
> > Sean.
> >
> >
> >
> > On Sun, 30 Jun 2019 at 22:24, Lizette Koehler 
> > wrote:
> >
> >> If this is a batch process to FTP to another platform, and it can handle
> >> tar or jar etc...
> >>
> >> Then you can certainly do that.
> >>
> >> If the other platform can use TRSMAIN output, that is part of z/OS
> >>
> >> So for your issue, you just need a first step to send the file to USS
> and
> >> pax or tar it.
> >>
> >> Then ftp to the other platform.  Once received there - you should be
> able
> >> to reverse the process
> >>
> >>
> >> There is some interesting information here
> >>
> >>
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-01.ibm.com%2Fsupport%2Fdocview.wss%3Fuid%3Disg1OA5data=02%7C01%7C%7C90d8eaf26b1547e8f6d908d6fe0bd459%7C84df9e7fe9f640afb435%7C1%7C0%7C636975724126831910sdata=HOwbwkzsXj%2BDlFJhl6yegpytyIiHHLa90AUmwmBtD2Y%3Dreserved=0
> >>
> >>
> >>
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.bpxa500%2Fmvsds.htmdata=02%7C01%7C%7C90d8eaf26b1547e8f6d908d6fe0bd459%7C84df9e7fe9f640afb435%7C1%7C0%7C636975724126831910sdata=eR61kd6UsyJuUucHmVjO6xVWOZH046s3ICvIpAmIQko%3Dreserved=0
> >>
> >>
> >> I have not done this myself, but I know it should be possible to do.
> >>
> >> Lizette
> >>
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List  On
> >> Behalf Of
> >>> Donald Russell
> >>> Sent: Sunday, June 30, 2019 8:58 AM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Using bpxbatch to compress an MVS dataset
> >>>
> >>> I have a batch process in zOS 2.1 (soon to be 2.3) that creates a large
> >> text
> >>> file I want to FTP to a zLinux system.
> >>>
> >>> How can I use bpxbatch tar or compress (or ?) to create a smaller file
> I
> >> can
> >>> ftp instead instead of the original file? I don’t want to use pkzip
> >> unless
> >>> that’s the only choice. Terse is no good because Linux can’t unterse
> it.
> >>>
> >>> Is there a way to specify a DD name for the input and output files,
> >> similar
> >>> to how FTP allows put/get //DD:
> >>>
> >>> Part two... the text in the file is EBCDIC, but Linux wants ASCII. I
> >> don’t
> >>> see an option to do the conversion.
> >>>
> >>> I’ll have to check tr, but maybe there’s a way to use more traditional
> >> Unix
> >>> syntax like
> >>>
> >>> cat //dd:in | tr ... | tar -cv //dd:out
> >>>
> >>> Cheers,
> >>> Don
> >>>
> >>> --
> >>> 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: Using bpxbatch to compress an MVS dataset

[Sean Gleann]

Donald: From your initial query... "Terse is no good because Linux can’t
unterse it."
FWIW there is a TERSE application available from the old Hercules days that
includes implementations for Windows, DOS, MAC and Linux.
I tried it out on windows and found it worked tolerably well for handling
TERSEd data moving in both directions, but I can't speak for the Linux
implementation.
If you can login to yahoo groups http://groups.yahoo.com/group/hercules-390
and go to 'files', you should be able to find the TERSE.ZIP distribution
file.

Regards
Sean.



On Sun, 30 Jun 2019 at 22:24, Lizette Koehler 
wrote:

> If this is a batch process to FTP to another platform, and it can handle
> tar or jar etc...
>
> Then you can certainly do that.
>
> If the other platform can use TRSMAIN output, that is part of z/OS
>
> So for your issue, you just need a first step to send the file to USS and
> pax or tar it.
>
> Then ftp to the other platform.  Once received there - you should be able
> to reverse the process
>
>
> There is some interesting information here
>
> https://www-01.ibm.com/support/docview.wss?uid=isg1OA5
>
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxa500/mvsds.htm
>
>
> I have not done this myself, but I know it should be possible to do.
>
> Lizette
>
>
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of
> > Donald Russell
> > Sent: Sunday, June 30, 2019 8:58 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Using bpxbatch to compress an MVS dataset
> >
> > I have a batch process in zOS 2.1 (soon to be 2.3) that creates a large
> text
> > file I want to FTP to a zLinux system.
> >
> > How can I use bpxbatch tar or compress (or ?) to create a smaller file I
> can
> > ftp instead instead of the original file? I don’t want to use pkzip
> unless
> > that’s the only choice. Terse is no good because Linux can’t unterse it.
> >
> > Is there a way to specify a DD name for the input and output files,
> similar
> > to how FTP allows put/get //DD:
> >
> > Part two... the text in the file is EBCDIC, but Linux wants ASCII. I
> don’t
> > see an option to do the conversion.
> >
> > I’ll have to check tr, but maybe there’s a way to use more traditional
> Unix
> > syntax like
> >
> > cat //dd:in | tr ... | tar -cv //dd:out
> >
> > Cheers,
> > Don
> >
> > --
> > 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: SDSF & REXX & ULOG problem

[Sean Gleann]

For what it's worth, an earlier modification of the REXX featured the use
of the WHO command to retrieve that sort of information.
The user is STCOPER, which doesn't have a TSO segment, it's true, even
though - per Itschak - one isn't necessary.
As part of pursuing this problem, I PERMITted both CONSOLE and SPECIAL
attributes for this user, as well as READ access to all resources inn the
SDSF class.
(have since backed those changes out, because they didn't move things
forward at all).

Regards
John

On Thu, 30 May 2019 at 13:48, ITschak Mugzach  wrote:

> Msg IKJ56644I is always issued. Tso batch does not requires tao segment.
> However, as John noticed this is not the same user. Has a look at the first
> message of the stc job log to see which user associated with your task and
> make sure it has permission to command ulog in sdsf resource class.
>
> ITschak
>
> בתאריך יום ה׳, 30 במאי 2019, 15:33, מאת John McKown ‏<
> john.archie.mck...@gmail.com>:
>
> > This is probably your problem:
> >
> > KJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
> >
> > What RACF ID is the job running under? It must have a TSO segment and be
> > authorized to use SDSF.
> >
> > On Thu, May 30, 2019 at 3:14 AM Sean Gleann 
> wrote:
> >
> > > I've been struggling with this one for a couple of days now, without
> > making
> > > any headway.
> > >
> > > I have a REXX that works through SDSF that is intended to issue 'D R,L'
> > > and retrieve any outstanding console messages. It works fine when I
> > invoke
> > > it from ISPF option 6 with an EXEC... command, but when I invoke it
> via a
> > > batch job or a started task it doesn't return the expected results.
> > >
> > > After a considerable amount of manual bashing and web browsing, I've
> > found
> > > a couple of threads describing a similar problem on various web fora,
> the
> > > most notable one having been raised back in 2011, and responded to by a
> > > number of the regular contributors here on IBM-MAIN.
> > >
> > > Unfortunately, I can't make the suggested modifications do anything for
> > me,
> > > and I'm hoping that someone here might be able to point me in a
> different
> > > direction.
> > >
> > > My REXX is:
> > > /* REXX */
> > > rc=isfcalls('ON')
> > > rc=syscalls('ON')
> > > isfcons="NODDY"
> > > Address SDSF ISFEXEC "'/D R,L' (wait"
> > > say "isfulog.0: "isfulog.0
> > > if isfulog.0>0 then do
> > >   do i=1 to isfulog.0
> > > say i isfulog.i
> > >   end
> > > end
> > > rc=isfcalls('OFF')
> > > rc=syscalls('OFF')
> > >
> > > When I run this via EXEC... in option 6, the result is:
> > > isfulog.0: 6
> > > 1 S0W1  2019150  03:02:03.62 ISF031I CONSOLE NODDY
> > > ACTIVATED
> > > 2 S0W1  2019150  03:02:03.62-D R,L
> > > 3 S0W1  2019150  03:02:03.62 IEE112I 03.02.03 PENDING
> > > REQUESTS 774
> > > 4RM=1IM=0 CEM=0
> > > EM=0 RU=0IR=0NOAMRF
> > > 5ID:R/K T SYSNAME
> > MESSAGE
> > > TEXT
> > > 638 R S0W1 *38
> > > DFS996I *IMS READY*  IVP1
> > > … which is exactly as expected.
> > >
> > > If I use a console START command to invoke the REXX via some started
> task
> > > JCL...
> > > //RUNEXEC  EXEC PGM=IKJEFT01,PARM='%'
> > > //SYSEXEC  DD   DSN=REXXLIB.SYSEXEC,DISP=SHR
> > > //SYSTSPRT DD   SYSOUT=*
> > > //SYSTSIN  DD   DUMMY
> > >
> > > ...the SYSTSPRT output on the hold queue is;
> > > IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
> > > isfulog.0: 0
> > > READY
> > > END
> > >
> > > As can be seen, the isfulog stem has simply gone west.
> > > The same occurs if I modify the JCL to turn it into a batch job and
> > invoke
> > > the REXX that way instead.
> > > I've tried a large number of variants of the REXX logic to trace it's
> > > progress, and in the hope of forcing something different to happen, all
> > to
> > > no avail.
> > >
> > > Any ideas, anyone... please?
> > >
> > > Regards
> > > Sean
> > >
> > > --
> > > For IBM

SDSF & REXX & ULOG problem

[Sean Gleann]

Please ignore my previous post.
I've manged to create a solution via a different method.
Using ADDRESS SDSF "ISFLOG READ TYPE(SYSLOG) (WTOR)" gives me what I need
to progress this work.

Regards
Sean

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

SDSF & REXX & ULOG problem

[Sean Gleann]

I've been struggling with this one for a couple of days now, without making
any headway.

I have a REXX that works through SDSF that is intended to issue 'D R,L'
and retrieve any outstanding console messages. It works fine when I invoke
it from ISPF option 6 with an EXEC... command, but when I invoke it via a
batch job or a started task it doesn't return the expected results.

After a considerable amount of manual bashing and web browsing, I've found
a couple of threads describing a similar problem on various web fora, the
most notable one having been raised back in 2011, and responded to by a
number of the regular contributors here on IBM-MAIN.

Unfortunately, I can't make the suggested modifications do anything for me,
and I'm hoping that someone here might be able to point me in a different
direction.

My REXX is:
/* REXX */
rc=isfcalls('ON')
rc=syscalls('ON')
isfcons="NODDY"
Address SDSF ISFEXEC "'/D R,L' (wait"
say "isfulog.0: "isfulog.0
if isfulog.0>0 then do
  do i=1 to isfulog.0
say i isfulog.i
  end
end
rc=isfcalls('OFF')
rc=syscalls('OFF')

When I run this via EXEC... in option 6, the result is:
isfulog.0: 6
1 S0W1  2019150  03:02:03.62 ISF031I CONSOLE NODDY ACTIVATED
2 S0W1  2019150  03:02:03.62-D R,L
3 S0W1  2019150  03:02:03.62 IEE112I 03.02.03 PENDING
REQUESTS 774
4RM=1IM=0 CEM=0
EM=0 RU=0IR=0NOAMRF
5ID:R/K T SYSNAME  MESSAGE
TEXT
638 R S0W1 *38
DFS996I *IMS READY*  IVP1
… which is exactly as expected.

If I use a console START command to invoke the REXX via some started task
JCL...
//RUNEXEC  EXEC PGM=IKJEFT01,PARM='%'
//SYSEXEC  DD   DSN=REXXLIB.SYSEXEC,DISP=SHR
//SYSTSPRT DD   SYSOUT=*
//SYSTSIN  DD   DUMMY

...the SYSTSPRT output on the hold queue is;
IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
isfulog.0: 0
READY
END

As can be seen, the isfulog stem has simply gone west.
The same occurs if I modify the JCL to turn it into a batch job and invoke
the REXX that way instead.
I've tried a large number of variants of the REXX logic to trace it's
progress, and in the hope of forcing something different to happen, all to
no avail.

Any ideas, anyone... please?

Regards
Sean

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

Re: REXX 'where did I come from' function?

[Sean Gleann]

Solved!
Thank you very much Tony and Binyamin
PARSE SOURCE cracked the problem nicely

Sean

On Wed, 1 May 2019 at 10:15, Binyamin Dissen 
wrote:

> Lookup PARSE SOURCE
>
>
>
> On Wed, 1 May 2019 09:38:05 +0100 Sean Gleann 
> wrote:
>
> :>Hello all
> :>I am developing a REXX that, for a number of reasons, needs to know the
> :>name of the PDS that it is stored in.
> :>The intention is that the REXX will be invoked from ISPF option 6, so
> :>typing something like:
> :>
> :>exec 'MY.REXX.LIB(TESTREXX)' 'MY.REXX.LIB'
> :>
> :>*is* an option, but one that is prone to error, and extra coding would be
> :>required to validate the passed parameter.
> :>What I really want is to be able to discover the 'MY.REXX.LIB' value
> within
> :>the REXX itself.
> :>Can anyone point me at a specific function (or whatever) that would do
> this?
> :>Is it even possible?
>
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
>
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

REXX 'where did I come from' function?

[Sean Gleann]

Hello all
I am developing a REXX that, for a number of reasons, needs to know the
name of the PDS that it is stored in.
The intention is that the REXX will be invoked from ISPF option 6, so
typing something like:

exec 'MY.REXX.LIB(TESTREXX)' 'MY.REXX.LIB'

*is* an option, but one that is prone to error, and extra coding would be
required to validate the passed parameter.
What I really want is to be able to discover the 'MY.REXX.LIB' value within
the REXX itself.
Can anyone point me at a specific function (or whatever) that would do this?
Is it even possible?

Regards
Sean

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

Re: Disk space allocation question [EXTERNAL]

[Sean Gleann]

Kees:
Ok, so - as I've found out for myself - "ALLOCxx does nothing for JCL." If
that is the case, then what is point of the various SPACE subparameters in
ALLOCxx? If they are coded, where or when *do* they come in to play? I
haven't seen anything in the Init guide that is specific on this point.

Up until reading the doc regarding ALLOCxx, I was unaware that "...Primary
space may be acquired in up to 5 extents" and that was the root cause of
the problem report that I was given. That doc and the further testing I've
done has allowed me to understand the numbers seen in the resulting ISPF
'I' command output, and to communicate that information to the person who
reported the 'problem' (I requested 9000 tracks! Why did I get only 7200?
Why did my job go to a B37 after that??)

There's a bit of confusion regarding "My JCL did not feature a SPACE
clause". The missing bit is that I'd commented out the SPACE clause *in
that particular test*. I'd expected the ALLOC values to take effect,
because there was nothing specified in SMS that could be used.

As for re-describing the problem, now that I've managed to explain to the
user how SPACE requests are fulfilled, the problem has been marked as
'solved' and I've been told to drop it.

Thanks to you and all others who have responded on this, but the user now
realises that they were reading the 'I' command output incorrectly.

Regards
Sean


On Wed, 6 Mar 2019 at 07:23, Vernooij, Kees (ITOP NM) - KLM <
kees.verno...@klm.com> wrote:

> RLSE in the Dataclas? This is a Mgmtclas option.
>
> Kees.
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Gibney, Dave
> > Sent: 05 March, 2019 23:19
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Disk space allocation question [EXTERNAL]
> >
> > My DEFAULT DATACLAS specifies a SPACE allocation, fairly large with
> > RLSE. This, plus space constraint relief, and also EXT as the DEFAULT
> > has eliminated almost all x37 abends here.
> > I also still run FDR COMPAK, fairly aggressive DFHSM migration to ML2
> > VTL, and a good sized overflow pool.
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Sean Gleann
> > > Sent: Tuesday, March 05, 2019 3:37 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Disk space allocation question [EXTERNAL]
> > >
> > > *sigh* I sometime wonder why I spend so much time making sure that
> > text
> > > positioning, justification, etc is 'just right', only to see all that
> > work thrown
> > > away.
> > > I hope those that read my previous response can make sense of it...
> > >
> > > Sean
> > >
> > > On Tue, 5 Mar 2019 at 11:32, Sean Gleann 
> > wrote:
> > >
> > > > Thanks to all who have responded on this. I've been having 'fun'
> > > > experimenting with allocating files of various sizes on a badly
> > > > fragmented disk volume and at least I now understand why an 'I'
> > > > command against a file shown in an ISPF 3.4 list occasionally shows
> > such
> > > surprising values.
> > > >
> > > > I don't appear to be able to make ALLOCxx settings (such as PRIM_ORG
> > > > or
> > > > RLSE) affect matters at all. I played around with various settings,
> > > > but all to no avail, but then I spotted Paul's response where he
> > says
> > > > "...ALLOC should not step in if you have SPACE coded in your
> > JCL...".
> > > > So I removed the SPACE clause in my DD statement... and the job
> > failed
> > > > with a JCL error and messages:
> > > > IEF344I jobname REQ911 REQ911 - ALLOCATION FAILED DUE TO DATA
> > > FACILITY
> > > > SYSTEM ERROR IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF
> > > DATA SET
> > > > The IGD... message means that "...No space was specified on the JCL
> > or
> > > > in the data class for the allocation of the data set..." which is
> > > > precisely the situation. My JCL did not feature a SPACE clause, and
> > my
> > > > SMS dataclass rule for the file in question has 'override space' set
> > > > to 'N', and no 'Space' values defined. I had expected ALLOC values
> > to
> > > > be used, but that did not happen.
> > > >
> > > > I'm not sure where to go from here. I cannot claim to be proficient
> > > > with SMS at all, so I don't really want to risk upsetting  a system
> > to
> > > > works (most

Re: Disk space allocation question [EXTERNAL]

[Sean Gleann]

*sigh* I sometime wonder why I spend so much time making sure that text
positioning, justification, etc is 'just right', only to see all that work
thrown away.
I hope those that read my previous response can make sense of it...

Sean

On Tue, 5 Mar 2019 at 11:32, Sean Gleann  wrote:

> Thanks to all who have responded on this. I've been having 'fun'
> experimenting with allocating files of various sizes on a badly fragmented
> disk volume and at least I now understand why an 'I' command against a file
> shown in an ISPF 3.4 list occasionally shows such surprising values.
>
> I don't appear to be able to make ALLOCxx settings (such as PRIM_ORG or
> RLSE) affect matters at all. I played around with various settings, but all
> to no avail, but then I spotted Paul's response where he says "...ALLOC
> should not step in if you have SPACE coded in your JCL...". So I removed
> the SPACE clause in my DD statement... and the job failed with a JCL error
> and messages:
> IEF344I jobname REQ911 REQ911 - ALLOCATION FAILED DUE TO DATA FACILITY
> SYSTEM ERROR
> IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET
> The IGD... message means that "...No space was specified on the JCL or in
> the data class for the allocation of the data set..." which is precisely
> the situation. My JCL did not feature a SPACE clause, and my SMS dataclass
> rule for the file in question has 'override space' set to 'N', and no
> 'Space' values defined. I had expected ALLOC values to be used, but that
> did not happen.
>
> I'm not sure where to go from here. I cannot claim to be proficient with
> SMS at all, so I don't really want to risk upsetting  a system to works
> (most of the time!)
>
> Regards
> Sean
>
>
> On Mon, 4 Mar 2019 at 15:50, Vernooij, Kees (ITOP NM) - KLM <
> kees.verno...@klm.com> wrote:
>
>> There are ACS options:
>> ACS routines can assign a Dataclass with Space Atributes plus the option
>> that it will override space in JCL, even for non-SMS managed datasets.
>> For SMS managed datasets, the DataClass' Space Constraint Relief options
>> can adjust space allocations.
>>
>> Kees
>>
>>
>> > -Original Message-
>> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On
>> > Behalf Of Feller, Paul
>> > Sent: 04 March, 2019 16:40
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: Disk space allocation question [EXTERNAL]
>> >
>> > It is my understanding that the ALLOC should not step if you have SPACE
>> > coded in your JCL.  By default you should get your space request, though
>> > it might be in more than one extent (up to 5).  Now if you have some 3rd
>> > party software installed it might be stepping in to prevent the initial
>> > X37 abend on allocation.  I don't recall if you could code something in
>> > the ACS routines to step in to adjust the primary allocation.
>> >
>> > Thanks..
>> >
>> > Paul Feller
>> > AGT Mainframe Technical Support
>> >
>> > -Original Message-
>> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On
>> > Behalf Of Elardus Engelbrecht
>> > Sent: Monday, March 04, 2019 6:33 AM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: Disk space allocation question [EXTERNAL]
>> >
>> > Sean Gleann wrote:
>> >
>> > >Does z/OS / SMS have a set of default space allocation sizes and if so,
>> > where are they held and can I alter or control them?
>> >
>> > Look in ALLOCxx as kindly suggested by Roger Lowe.
>> >
>> > If you know what SMS routines were used, look at their definitions.
>> >
>> >
>> > >I have a situation where insufficient contiguous disk space results in
>> > the SPACE request parameters supplied for a DISP=(NEW...) file with
>> > values that are too low to fulfil the final requirements.
>> > >Example: I request SPACE=(TRK,(9000,1000)… and what I get is
>> > ...TRK,(7200,500), which eventually leads to a B37 abend.
>> >
>> > Please post that full B37 abend message. There may be another reason why
>> > you are not getting what you want.
>> >
>> > What about trying to use more than one volser for your allocation
>> > attempts?
>> >
>> >
>> > >It's that 'eventually' bit that is most disheartening. I would far
>> > rather have the space request completely refused along with a job abend
>> > rather than have the 

Re: Disk space allocation question [EXTERNAL]

[Sean Gleann]

Thanks to all who have responded on this. I've been having 'fun'
experimenting with allocating files of various sizes on a badly fragmented
disk volume and at least I now understand why an 'I' command against a file
shown in an ISPF 3.4 list occasionally shows such surprising values.

I don't appear to be able to make ALLOCxx settings (such as PRIM_ORG or
RLSE) affect matters at all. I played around with various settings, but all
to no avail, but then I spotted Paul's response where he says "...ALLOC
should not step in if you have SPACE coded in your JCL...". So I removed
the SPACE clause in my DD statement... and the job failed with a JCL error
and messages:
IEF344I jobname REQ911 REQ911 - ALLOCATION FAILED DUE TO DATA FACILITY
SYSTEM ERROR
IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET
The IGD... message means that "...No space was specified on the JCL or in
the data class for the allocation of the data set..." which is precisely
the situation. My JCL did not feature a SPACE clause, and my SMS dataclass
rule for the file in question has 'override space' set to 'N', and no
'Space' values defined. I had expected ALLOC values to be used, but that
did not happen.

I'm not sure where to go from here. I cannot claim to be proficient with
SMS at all, so I don't really want to risk upsetting  a system to works
(most of the time!)

Regards
Sean


On Mon, 4 Mar 2019 at 15:50, Vernooij, Kees (ITOP NM) - KLM <
kees.verno...@klm.com> wrote:

> There are ACS options:
> ACS routines can assign a Dataclass with Space Atributes plus the option
> that it will override space in JCL, even for non-SMS managed datasets.
> For SMS managed datasets, the DataClass' Space Constraint Relief options
> can adjust space allocations.
>
> Kees
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Feller, Paul
> > Sent: 04 March, 2019 16:40
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Disk space allocation question [EXTERNAL]
> >
> > It is my understanding that the ALLOC should not step if you have SPACE
> > coded in your JCL.  By default you should get your space request, though
> > it might be in more than one extent (up to 5).  Now if you have some 3rd
> > party software installed it might be stepping in to prevent the initial
> > X37 abend on allocation.  I don't recall if you could code something in
> > the ACS routines to step in to adjust the primary allocation.
> >
> > Thanks..
> >
> > Paul Feller
> > AGT Mainframe Technical Support
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Elardus Engelbrecht
> > Sent: Monday, March 04, 2019 6:33 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Disk space allocation question [EXTERNAL]
> >
> > Sean Gleann wrote:
> >
> > >Does z/OS / SMS have a set of default space allocation sizes and if so,
> > where are they held and can I alter or control them?
> >
> > Look in ALLOCxx as kindly suggested by Roger Lowe.
> >
> > If you know what SMS routines were used, look at their definitions.
> >
> >
> > >I have a situation where insufficient contiguous disk space results in
> > the SPACE request parameters supplied for a DISP=(NEW...) file with
> > values that are too low to fulfil the final requirements.
> > >Example: I request SPACE=(TRK,(9000,1000)… and what I get is
> > ...TRK,(7200,500), which eventually leads to a B37 abend.
> >
> > Please post that full B37 abend message. There may be another reason why
> > you are not getting what you want.
> >
> > What about trying to use more than one volser for your allocation
> > attempts?
> >
> >
> > >It's that 'eventually' bit that is most disheartening. I would far
> > rather have the space request completely refused along with a job abend
> > rather than have the system 'try to help' me.
> >
> > Buy more disks... ;-)
> >
> > Pre-allocations may help before you actually use it, but of course, how
> > do you know what size is 'correct'?
> >
> > 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
> >
> > --
> > Please note:  This message originated outside your organization. Please
> > use caution when opening links or attachments.
> >

Disk space allocation question

[Sean Gleann]

Does z/OS / SMS have a set of default space allocation sizes and if so,
where are they held and can I alter or control them?
I have a situation where insufficient contiguous disk space results in
the SPACE request parameters supplied for a DISP=(NEW...) file with values
that are too low to fulfil the final requirements.
Example: I request SPACE=(TRK,(9000,1000)… and what I get
is ...TRK,(7200,500), which eventually leads to a B37 abend.
It's that 'eventually' bit that is most disheartening. I would far rather
have the space request completely refused along with a job abend rather
than have the system 'try to help' me.

Regards
Sean

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

Re: [EXTERNAL] Re: how many OSes run on IBMz

[Sean Gleann]

I remember having maintain a PICK system w back
https://en.wikipedia.org/wiki/Pick_operating_system


On Mon, 28 Jan 2019 at 09:20, Sankaranarayanan, Vignesh <
vignesh.v.sankaranaraya...@marks-and-spencer.com> wrote:

> Hi Arthur,
>
> Thank you, always open to history lessons 
> Didn't mean to attempt to give an actual explanation as such.. was just
> thinking of it in a comical sense, that's all.
>
> – Vignesh
> Mainframe Infrastructure
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Arthur Fichtl
> Sent: 27 January 2019 13:11
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: how many OSes run on IBMz
>
> BS = bull $hit
>
> Meaning,.. one is talking meaningless, foolish, s#it. So either BS or
> horse s#it.
>
> Seeing a name like BS2000 or BS3000 made me think of a hypothetical
> marketing department where their product is so useless, but they proudly
> sell it, by naming it BS2000.
>
> They call the new and improved version BS3000.
>
> It's like how the wall street laughs at the rest of the world when they
> name things CDOs, etc.
>
> Sure, CDO has a normal meaning but I'm sure some guy in a suit somewhere
> knows its *real* expanded name (inside joke).
>
> – Vignesh
>
> Mainframe Infrastructure
>
> Vignesh, that’s not correct.
>
> As I worked (in an earlier life) both with BS2000 and BS3000 I could
> enlight you:
>
> Beginning 1966 Siemens/Germany started with manufacturing Computers whose
> design was developed by RCA (USA). It was named BS1000 and was similar to
> the IBM/360 (but not identical).
>
> When IBM started selling the /370 machines which where equipped with a
> virtual memory hardware architecture and ran the successor Operating System
> named OS/VS, Siemens began to produce its own Hardware and developed an OS
> called BS2000, as well equipped with virtual memory.
>
> Regarding the /370 you might want to have a look to this article:
>
> https://en.wikipedia.org/wiki/IBM_System/370
>
> BS3000 was marketed by Siemens (its original name was FACOM and the
> manufacturer was Fujitsu). It had no relations to BS2000.
>
> It was sort of Clone of MVS and IBM sued Fujitsu for copyright
> infringement; there were rumors that IBM demanded (and received) 1 billion
> US$ from Fujitsu which implied also that the Japanese company was allowed
> to sell their machines in the domestic market.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> MARKSANDSPENCER.COM
> 
>  Unless otherwise stated above:
> Marks and Spencer plc
> Registered Office:
> Waterside House
> 35 North Wharf Road
> London
> W2 1NW
>
> Registered No. 214436 in England and Wales.
>
> Telephone (020) 7935 4422
> Facsimile (020) 7487 2670
>
> www.marksandspencer.com
>
> Please note that electronic mail may be monitored.
>
> This e-mail is confidential. If you received it by mistake, please let us
> know and then delete it from your system; you should not copy, disclose, or
> distribute its contents to anyone nor act in reliance on this e-mail, as
> this is prohibited and may be unlawful.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

ZFS File System SMF data synchronisation query

[Sean Gleann]

Wondering if anyone is doing anything with data from SMF type 92, subtypes
50-59...

These subtypes are generated if IOEFSPRM specifies
"smf_recording=On,", but there does not appear to be a way to
synchronise the recording interval with rest of SMF data.
If you know of a way to do this synchronisation, I'd appreciate hearing how
to do it.

At present, I've got collection of these subtypes switched on with
"smf_recording=On,15", and for comparison purposes, I've also got a timed
JES command issuing 'F ZFS,QUERY,ALL'  (immediately followed by a 'F
ZFS,RESET,ALL') every 15 minutes, on the 15-minute mark. The timestamps of
the two sets of data just never match up. Sure, long-term totals are in
*close* agreement, but even then I'm seeing differences that make accurate
performance analysis a bit questionable.

Also, there are differences in other data items. For instance, 'F
ZFS,QUERY,KNPFS' generates a table on the SYSLOG showing PFS call types
along with counts and average time per call. In the equivalent SMF record
92(51) data, the average time values are always zero.

As yet it's early days in my efforts to make use of this data, but I'm
expecting to see plenty more difficulties as I delve deeper in to it.

Regards
Sean

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

Re: System Symbols

[Sean Gleann]

Just for clarification:
No, we don't IPL daily - apologies for my poor wording.
My use of IEASYMU2 creates two 'new' system symbols 'PRYYMMDD' and
'PRYYDDD' after IPL, but then I change the values in those symbols at about
00:01 each day.

As for "This is the sort of thing that should be routinely provided by the
OS." - a huge YES! to that, and other associated values like 'first working
day of the week/month/year' and so on.
Its a crying shame that the only other way of getting such values in  to a
jobstream - that I know of! - is by spending $many for something like CA-7
or Tivoli.

Sean

On Sun, 30 Dec 2018 at 22:55, scott Ford  wrote:

> Peter ,
>
> Do customers typically add their own SYS type symbols ? I am curious.
>
> Scott
>
> On Sun, Dec 30, 2018 at 8:44 AM Peter Relson  wrote:
>
> > Using IEASYMU2 is fine.
> >
> > I suspect that most would not use "routinely" to express the desirability
> > of IBM providing a symbol for "yesterday".
> > I have not seen a requirement for such a thing (this would be a "dynamic
> > symbol" rather than a "static symbol").
> > FWIW, at this point, compatibility would be a concern with adding any
> > symbol that does not begin with "SYS".
> >
> > So Sean's implementation of a symbol for his own site makes sense.
> >
> > Peter Relson
> > z/OS Core Technology Design
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
> --
> 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: System Symbols

[Sean Gleann]

@ Peter Relson
Peter, you say "Adding system symbols is not something that a program
should be doing".
By 'a program', do you mean 'a user-written program', as opposed to a
'system utility'?
I'm using IEASYMU2 on a daily basis to create (immediately after IPL) or
update 2 system symbols.
These symbols contain date values for 'yesterday' in Gregorian and Julian
formats, which I then use in a number of daily data collection/archival
jobs.
I hope I'm not doing something dangerous...

Regards
Sean

On Sat, 29 Dec 2018 at 18:37, scott Ford  wrote:

> Peter,
>
> Exactly. I saw the responses after I read through the manual, just wanted
> to make sure I understood
> the process before thinking about a design. In theory, we would have
> customer set the symbol and use the
> Service to query it as you had indicated.
>
> As always Peter, very much appreciated, and I learned someone again.
>
> Regards,
> Scott
>
> On Sat, Dec 29, 2018 at 10:15 AM Peter Relson  wrote:
>
> > 
> > Has anyone created their own system symbol and then referenced it in
> HLASM
> > ?
> > 
> >
> > Adding system symbols is not something that a program should be doing.
> > IEASYMxx is the supported method for defining system symbols.
> > SETLOAD IEASYM is the supported method for adding a system symbol after
> > IPL.
> >
> > 
> > what I am not clear on is how to have HLASM code read the system symbol
> > table and compare for the desired symbol.What i want to do is if we find
> a
> > specific symbol set, have a exit perform conditional logic.
> > 
> >
> > You should not "read the system symbol table". If you want to see if a
> > specific symbol is set, then you should use the ASASYMBM service to try
> to
> > substitute a string that has that symbol in it and see if substitution
> > occurred.
> >
> > This of course is very inefficient, and unless this will happen only once
> > in the life of the system you would be better off doing this once,
> > somewhere, and stashing the result so that subsequent times can get the
> > result quickly.
> >
> > Peter Relson
> > z/OS Core Technology Design
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
> --
> 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: Region size for OMVS tasks

[Sean Gleann]

Sorry for not coming back earlier - a minor panic at this end took
precedence…

Elardus: "...despite all the tuning and resizing attempts, it was... "
Precisely so. No matter what I did at the global level, the developer was
overriding with his own specification.
He had completely missed the significance of the string '768M' in his
command, and I had not been party to actually running the test.
In the event, the developer sent me a screen shot that showed both the
REXXSTOR output *and* the command text.
One look from my 'different set of eyes' was enough to crack the problem.

Seymour: I've often considered the idea of a simple cardboard cut-out of a
figure - not necessarily human! - mounted on a spring such that it appears
to nod or shake it's head as it bounces. Place this 'device' on your desk
beside you as you perform a personalised 'walk-through' of your problem
program, and I'm fairly certain that the time taken for problem
determination and source identification would be at least halved...
One day I'll get around to making such a thing.

Regards
Sean


On Mon, 26 Nov 2018 at 19:21, Seymour J Metz  wrote:

>  1. A different set of eyes is always an asset
>
>  2. Sometimes when I explain a problem to a different set of eyes I see
> the solution myself;
> there seems to be a psychological difference between explaining
> something and analyzing it
>
>  3. If you can reproduce the problem, that helps; if you can reproduce it
> with instrumentation
> turned on, you're hallway to a solution.
>
>  4. Check your assumptions, especially about version control.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> ____
> From: IBM Mainframe Discussion List  on behalf
> of Sean Gleann 
> Sent: Monday, November 26, 2018 6:14 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Region size for OMVS tasks
>
> Hello Peter
> Problem solved!
> Your idea(s) regarding the SMF30 record analysis eventually led me to
> reproducing the test environment used by the developer so that I could run
> the tests myself.
> One look at the command being used showed what the problem was - there was
> a parametrised upper limit of 768M on the memory to be used. The
> developer had completely missed this information. Bumping the parm value to
> 1G was enough to get the test through, but I'm still arguing for all such
> limits to be removed - "let the system sort itself out, don't try and
> 'second guess' things..."
>
> Such a simple thing, spotted by a different set of eyes being used, but
> that's frequently the root cause in problems such as  this, I find.
>
> Also, your comment about chopping columns off the REXXSTOR output showed
> that I was using an old version of Mark's work. That has been addressed.
>
> Thank you very much for all your efforts and input on this. I really
> appreciate it.
>
> Regards
> Sean
>
> On Fri, 23 Nov 2018 at 06:35, Peter Hunkeler  wrote:
>
> >
> >
> > One more thought: Look At he SMF30 records for one such session. You
> > should get an idea of what‘s going on in that process and its child
> > processes. There will be one record  for each command, i.e. when a
> fork()ed
> > or spawd()ed process ends, and at each exec(). You may find the one
> program
> > eating up all that storage.
> >
> >
> > —
> > 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
>
> --
> 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: Region size for OMVS tasks

[Sean Gleann]

Hello Peter
Problem solved!
Your idea(s) regarding the SMF30 record analysis eventually led me to
reproducing the test environment used by the developer so that I could run
the tests myself.
One look at the command being used showed what the problem was - there was
a parametrised upper limit of 768M on the memory to be used. The
developer had completely missed this information. Bumping the parm value to
1G was enough to get the test through, but I'm still arguing for all such
limits to be removed - "let the system sort itself out, don't try and
'second guess' things..."

Such a simple thing, spotted by a different set of eyes being used, but
that's frequently the root cause in problems such as  this, I find.

Also, your comment about chopping columns off the REXXSTOR output showed
that I was using an old version of Mark's work. That has been addressed.

Thank you very much for all your efforts and input on this. I really
appreciate it.

Regards
Sean

On Fri, 23 Nov 2018 at 06:35, Peter Hunkeler  wrote:

>
>
> One more thought: Look At he SMF30 records for one such session. You
> should get an idea of what‘s going on in that process and its child
> processes. There will be one record  for each command, i.e. when a fork()ed
> or spawd()ed process ends, and at each exec(). You may find the one program
> eating up all that storage.
>
>
> —
> 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: Region size for OMVS tasks

[Sean Gleann]

Peter, Mike: Yes, I remember Peter pointing at Mark's page, but for some
reason I moved on past that to some other line of enquiry.
I've now done what you said, and the results from REXXSTOR in PuTTY are:

V I R T U A LS T O R A G EU S A G E
---
REGION REQUESTED: 55296K
LIMIT IN-USE  AVAIL
BELOW 16M:  8168K 4K  8164K
ABOVE 16M:   2088984K   840K   2088144K

So, the 55296K is that 54M that I've been chasing
and the rest of the report shows that I've been given the maximum amount of
memory possible - 2G, right?

So this whole exercise along with the temporary killing of my z/OS system
*has* been a waste of time.

I'm still left with the two messages though.
And further work by one of the developers shows that the problem occurs
only when BPX_SHAREAS=YES is defined.
Setting BPX_SHAREAS=NO makes the memory problem go away, but run-time
increases significantly.


Thanks for all your support on this problem, Peter - and everyone else who
added their thoughts, too.
(I'm not letting this problem go though - this is one of those times when I
start behaving like a terrier with a rat)

Regards
Sean



On Thu, 22 Nov 2018 at 15:44, Peter Hunkeler  wrote:

>
>
>
> >http://mzelden.com/mvsutil.html
>
>
>
> Yep, this is the invaluable link. As I wrote before, try the REXXSTOR rexx
> found there and run it in a) TSO, b) TSO -> OMVS (shell under TSO), c)
> putty (shell vie TCP/IP). If possible run in the environment where you‘re
> getting the out of stroage, and run it under the userid that is getting the
> problem. This may or may not give you a hint what to do next
>
>
> —
> 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: Region size for OMVS tasks

[Sean Gleann]

Thanks to all that have responded - we're back and running again, but not
due to any work on my part.



My description of the failed system was not complete, for fear of confusing
the issue - it is a guest z/OS under z/VM that is supplied by a.n. other
party. I contacted them and the bad IEFUSI was renamed by a techie at their
end.



Rob: thanks for the referral to cbttape. I wasn't aware of that particular
file there. I'll take a closer look later. I've had the comfort of a
recovery system in the past. Sadly, that wasn't an option for me in this
case.



Peter: "...[54m value] has no meaning and will later be replaced..." Yes -
Overnight I began to understand that.

No matter what I've done so far, that SMF30RGN value continues to report
'54M'. I 'new' thought for me in the course of this work is that SMF30RGN
is the REGION size that was _requested_ (as per the documentation). It is
not the size actually _given_ after IEFUSI/SMF/JES, etc have finished their
meddling. As far as I make out, there is no such 'after the fact' value
logged in any part of the type30 record (or any other).

Which basically means that all this work has been a waste of time, based on
a misconception.



Peter again: [paging space related to the problem]... sorry - my poor
description there. The alternate SYS1.IPLPARM(LOADxx) member leads to an
incomplete definition that does not specify any paging space, so it won't
IPL.



Carmen and Peter: I simply did not think about the possibilities of SETPROG
EXIT..., My mind was chasing itself in circles at the time. And then the
supplier's technician fixed things up.





I must re-visit my failed 'back-out' LOADPARM member and make sure it
brings up a minimal system - possibly with whatever I find on the cbttape.

And abandon this line of effort - I'm pretty certain that SMF30RGN point
above is correct.



Unfortunately, that leaves the cause  of the original IEW4000I and CSV031I
messages unsolved. I will have to think of a different way to attack the
problem.


Regards

Sean


On Wed, 21 Nov 2018 at 20:23, Peter Hunkeler  wrote:

> Just recognized that the parameter STATE=INACTIVE was missing in my
> previous post
>
> SETPROG EXIT,MODIFY,EXITNAME=SYS.IEFUSI,MODNAME=IEFUSI,STATE=INACTIVE
>
>
> --
>
> 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: Region size for OMVS tasks

[Sean Gleann]

Thanks, Allan, but I can't get any tasks of any nature started - no VTAM,
no TSO, so no copy is possible.
(I'll squirrel that 'SYS1.AOSB3' info away, though, for possible future
reference - hopefully never)

Sean

On Wed, 21 Nov 2018 at 16:38, Allan Staller  wrote:

> If you have customized IEFUSI, reassemble you customized exit.
> IF not, copy SYS1.AOSB3 to SYS1.LLPALIB and re-ipl.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Sean Gleann
> Sent: Wednesday, November 21, 2018 10:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Region size for OMVS tasks
>
> Trying to follow-up on the stuff that Peter has suggested, I'm still
> chasing that elusive '54M' - Who sets it? Where is it set? How can I
> override it?
> So, I created an IEFUSI that, whatever size is requested, whether it be
> below, above or MEMLIMIT, you get '0M'.
> Which, I agree, is probably a bit extreme, so I armed myself with an
> IDCAMS job in 'HOLD' on the input queue to do a DELETE xxx.LPALIB(IEFUSI),
> that I could release if things went pear-shaped.
> System had a certain amount of … umm … 'difficulty' in restarting, but JES
> itself started, so $AJ worked OK.
> But all the inits go to a 922 abend when they try to start. so the delete
> job never got a chance.
> Now I've got a system that won't IPL at all beyond a certain point.
> Have tried alternate members from SYS1.IPLPARM, but none of then specify
> sufficient paging space.
>
> Up the creek sans paddle, right now
>
> Sean
>
> On Tue, 20 Nov 2018 at 20:01, Peter Hunkeler  wrote:
>
> > > Where did you get all this from? Is it documented somewhere, or is
> > > it
> > something you've 'soaked up through your fingertips' over the years?
> >
> >
> > So I went back to the FMs. For any question of kind "How does that
> > UNIX service behave regarding MVS resources, attributes, etc.", I
> > always read what the "z/OS UNIX System Services Programming -
> > Assembler Callable Services Reference" tells me. If something is to be
> > said, there is a section called "Usage Notes". Here are some interesting
> snippet:
> >
> >
> > For fork() it says:
> >
> > - The child process inherits the MEMLIMIT of the parent.
> > - The child address space inherits the following address space
> > attributes of the parent address space: region size and time limit.
> >
> >
> > For spawn() it says:
> >
> > - The region size of the parent is inherited by the child, unless the
> > INHESETREGIONSZ flag in the inheritance structure is set on to
> > indicate that the value specified in INHEREGIONSZ is to be used to
> > determine the child's region size. For more information, see What are
> > soft limits? in z/OS UNIX System Services Planning and Inheriting soft
> > limits in z/OS UNIX System Services Planning.
> >
> > - The MEMLIMIT of the parent is inherited by the child, unless the
> > INHESETMEMLIMIT flag in the inheritance structure is set on to
> > indicate that the value specified in INHEMEMLIMIT is to be used to
> > determine the child's MEMLIMIT.
> >
> >
> > Another useful source of information is "z/OS UNIX System Services
> > Planning". This FM says about MAXASSIZE:
> >
> > MAXASSIZE is the maximum region size (in bytes) for an address space
> > that was created by rlogind, telnetd, and other daemons. The MAXASSIZE
> > value limits the combined size of above and below the 16 M line storage.
> > If MAXASSIZE is greater than LDALIMIT (the <16M limit), then the
> > LDAELIM (the >16M limit) is set to MAXASSIZE - LDALIM.
> >
> > You can set a system-wide limit in BPXPRMxx and then set higher limits
> > for individual processes. Use the RACF ADDUSER or ALTUSER command to
> > specify the ASSIZEMAX limit on a per-process basis as follows:
> > ALTUSER userid OMVS(ASSIZEMAX()
> >
> >
> > This manual also has a couple of pages discussing all about limits. Of
> > special interest to this discussion it the section called "How are
> > limits handled after an identity change?", and the following sections.
> > Its too much to copy here. I suggets you have a read if your
> > interested. (I've got the impression this part has not always be there
> > in that detail. Great it is now)
> >
> >
> > --
> >
> > Peter Hunkeler
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
&g

Re: Region size for OMVS tasks

[Sean Gleann]

Trying to follow-up on the stuff that Peter has suggested, I'm still
chasing that elusive '54M' - Who sets it? Where is it set? How can I
override it?
So, I created an IEFUSI that, whatever size is requested, whether it be
below, above or MEMLIMIT, you get '0M'.
Which, I agree, is probably a bit extreme, so I armed myself with an IDCAMS
job in 'HOLD' on the input queue to do a DELETE xxx.LPALIB(IEFUSI), that I
could release if things went pear-shaped.
System had a certain amount of … umm … 'difficulty' in restarting, but JES
itself started, so $AJ worked OK.
But all the inits go to a 922 abend when they try to start. so the delete
job never got a chance.
Now I've got a system that won't IPL at all beyond a certain point.
Have tried alternate members from SYS1.IPLPARM, but none of then specify
sufficient paging space.

Up the creek sans paddle, right now

Sean

On Tue, 20 Nov 2018 at 20:01, Peter Hunkeler  wrote:

> > Where did you get all this from? Is it documented somewhere, or is it
> something you've 'soaked up through your fingertips' over the years?
>
>
> So I went back to the FMs. For any question of kind "How does that UNIX
> service behave regarding MVS resources, attributes, etc.", I always read
> what the "z/OS UNIX System Services Programming - Assembler Callable
> Services Reference" tells me. If something is to be said, there is a
> section called "Usage Notes". Here are some interesting snippet:
>
>
> For fork() it says:
>
> - The child process inherits the MEMLIMIT of the parent.
> - The child address space inherits the following address space
> attributes of the parent address space: region size and time limit.
>
>
> For spawn() it says:
>
> - The region size of the parent is inherited by the child, unless the
> INHESETREGIONSZ flag in the inheritance structure is set on to indicate
> that the value specified in INHEREGIONSZ is to be used to determine the
> child's region size. For more information, see What are soft limits? in
> z/OS UNIX System Services Planning and Inheriting soft limits in z/OS
> UNIX System Services Planning.
>
> - The MEMLIMIT of the parent is inherited by the child, unless the
> INHESETMEMLIMIT flag in the inheritance structure is set on to indicate
> that the value specified in INHEMEMLIMIT is to be used to determine the
> child's MEMLIMIT.
>
>
> Another useful source of information is "z/OS UNIX System Services
> Planning". This FM says about MAXASSIZE:
>
> MAXASSIZE is the maximum region size (in bytes) for an address space
> that was created by rlogind, telnetd, and other daemons. The MAXASSIZE
> value limits the combined size of above and below the 16 M line storage.
> If MAXASSIZE is greater than LDALIMIT (the <16M limit), then the LDAELIM
> (the >16M limit) is set to MAXASSIZE - LDALIM.
>
> You can set a system-wide limit in BPXPRMxx and then set higher limits
> for individual processes. Use the RACF ADDUSER or ALTUSER command to
> specify the ASSIZEMAX limit on a per-process basis as follows:
> ALTUSER userid OMVS(ASSIZEMAX()
>
>
> This manual also has a couple of pages discussing all about limits. Of
> special interest to this discussion it the section called "How are
> limits handled after an identity change?", and the following sections.
> Its too much to copy here. I suggets you have a read if your
> interested. (I've got the impression this part has not always be there
> in that detail. Great it is now)
>
>
> --
>
> 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: Region size for OMVS tasks

[Sean Gleann]

Thanks for the responses, gents
Carmen: yes - that is what I see in the manual
Jim: Thanks for the update - it would appear that the manual requires an
update
Peter: I'm still trying to fully assimilate what you've said - very
detailed & complete. Where did you get all this from? Is it documented
somewhere, or is it something you've 'soaked up through your fingertips'
over the years?

I have to say that even after 40 years on mainframes I still don't fully
understand this kind of memory-associated stuff
I can understand that it's rooted in the past when 'memory' was expensive
so it had to be protected from over-commitment.
These days, though, I find it next to impossible to justify insufficient
physical memory; it's so cheap (comparatively speaking), there's just no
excuse.
Even if your environment is thus limited then paging to/from disks on a
RAID array removes most of any remaining constraints.
Given that (probably poorly-informed) stance, then REGION and MEMLIMIT
limits become pretty much meaningless. Don't they?

Regards
Sean


On Tue, 20 Nov 2018 at 07:49, Peter Hunkeler  wrote:

>
>
> From fading memory, so things might have change slightly, but I think most
> of this still applies.
>
>
> The REGION and MEMLIMIT values that apply to z/OS UNIX processes depend on
> how and where the process is running:
>
>
> a) BATCH jobs, started tasks, TSO user sessions
> A program run as batch job, started task, or in a TSO session gets its
> REGION and MEMLIMIT via JCL, which may be changed by IEFUSI (and IEFLIMIT).
> When this program makes use of z/OS UNIX services, it will become dubbed,
> i.e. it becomes a UINX process. It still runs in the same address space.
> Nothing changes with respect to REGION or MEMLIMT.
>
>
> When this process spawn()s (non-local spawn) or fork()s a new process,
> that new process will be in a BPXAS address space. REGION and MEMLIMT will
> be inherited from the originating batch job address space. None of the z/OS
> UNIX settings apply.
>
>
> IEFUSI will gin control in the BPXAS address space before the UNIX process
> gets control. OMVS set REGION to the magic value 54M. This has not meaning
> and will later be replaced by the values from the originating batch job. (I
> don‘t know why 54M was chosen as the indicator value.)
>
>
> b) If a z/OS UNIX process is a daemon, such as FTPD, otelnetd, etc. which
> listens for incoming session calls, then authenticates the new user, and
> spawn()s / fork()s a new process for this new user, then REGION and
> MEMLIMIT will be set from the z/OS UNIX parameters (ASSIZEMAX/MAXASSIZE,
> etc). It is not useful to inherit those values from the parent process in
> these cases. The parent is the server, the childs are the unser sessions.
> They serve different means.
>
>
> So, your IEFUSI should not touch the REGION and MEMLIMIT field when it is
> called for OMVS address spaces (see flags as described in the IEFUSI
> description). And, for the putty sessions, the MAXASSIZE or ASSIZEMAX value
> should apply. Try to run Mark Zelden‘s REXXSTOR in a TSO session, after TSO
> OMVS, and in a putty session to see the differences
>
>
> From the „z/OS MVs Installation Exits“ manual:
> Additional Considerations for z/OS UNIX Applications:
> When running z/OS UNIX applications you need to consider that fork and
> spawn are issued to create new address spaces. The default processing on
> fork and spawn is for the z/OS UNIX kernel to propagate the region size
> from the parent to the child. Because the region size in the parent process
> has already passed through IEFUSI and has an approved region size, IBM
> recommends that you bypass normal IEFUSI processing when the subsystem
> (Word 8) is OMVS.
>
>
> At the time of IEFUSI processing, the kernel has not yet propagated the
> parent's region size to the child, so IEFUSI has nothing to work with. If
> IEFUSI modifies the region size of the child process, the kernel will honor
> that region size and not propagate the region size from parent to child.
> This can result in failure of a fork if the region size is insufficient in
> the child to capture the parent's storage.
>
>
>  --
> 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: Region size for OMVS tasks

[Sean Gleann]

Interesting stuff, here...
Before making any changes, analysis of the type-30 data showed
SMF30RGN=56623104 (54M) and SMF30MES - the source of MEMLIT - as '1', which
apparently means that MEMLIMIT is set by SMF. Also, SMF30MEM was coming
back as 1280M - the same as the MEMLIMIT in SMFPRMxx. So far, so good.
So I set the ASSIZEMAX for my own profile to 2G and logged off-n-on. No
change in the type-30 values
Then I set the associated MEMLIMIT value to 2G & logged off and on again.
This time, SMF30MEM is coming back as 2048M. Great! I can modify the
MEMLIMIT value and perhaps solve my problem. I'll have to re-engage one of
the developers for that, could take a bit of time.
But a curiosity has cropped up along the way...
Now, my SMF30MES is coming back as '5' - which is undocumented, according
to the System Management Facilities manual I'm using (SA22-7630-26 - which
I believe is the latest, though I stand to be corrected). Apparently, the
values for SMF30MES can be one of 1, 2, 3, 4 or 10 (decimal), so where the
'5' is coming from is a mystery. I'm not sure it's important and I shan't
chase it up with IBM, but thought it worth mentioning.

Sean

On Mon, 19 Nov 2018 at 15:38, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Sean Gleann wrote:
>
> >None of the suggestions so far check out, unfortunately.
> >David: all limits associated with memory come back as 'Unlimited'
> >Carmen: Yes, I've got MEMLIMIT(1280M) specified
> >Alan: BPXPRMxx MAXASSIZE is set to 2G, and the OMVS segment ASSIZEMAX and
> >MEMLIMT values are not specified, so they default to something.
> >Hmmm  that may be a way forward - play with one or both those settings to
> see what happens.
>
> Check out your OMVS segment in RACF. AFAIK - RACF overrides nearly
> everything above.
>
> Increase these in RACF these parts in the OMVS segment: ASSIZEMAX,
> FILEPROCMAX, PROCUSERMAX, THREADSMAX, MMAPAREAMAX
>
> I know you said ASSIZEMAX, but just set it and increase it (in large
> chunks).
>
> Let us know what your solution is. Good luck!
>
> 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
>

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

Re: Region size for OMVS tasks

[Sean Gleann]

None of the suggestions so far check out, unfortunately.
David: all limits associated with memory come back as 'Unlimited'
Carmen: Yes, I've got MEMLIMIT(1280M) specified
Alan: BPXPRMxx MAXASSIZE is set to 2G, and the OMVS segment ASSIZEMAX and
MEMLIMT values are not specified, so they default to something.
Hmmm  that may be a way forward - play with one or both those settings to
see what happens.
I'll let you know how my testing pans out.
Thank you, gentlemen.

Sean


On Mon, 19 Nov 2018 at 14:25, Allan Staller  wrote:

> Check MAXASSIZE in BPXPRMxx
> Check Check ASSIZEMAX and MEMLIMT in the OMVS segment for the UID in
> question
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Carmen Vitullo
> Sent: Monday, November 19, 2018 8:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Region size for OMVS tasks
>
> do you have a MEMLIMIT in the SMFPRMxx member ?
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Sean Gleann" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Monday, November 19, 2018 7:51:04 AM
> Subject: Region size for OMVS tasks
>
> We have a problem here that is proving to be … um... "resistant to
> analysis" & I wonder if anyone on this list might be able to help.
>
> Most of our developers submit work to the system from a PuTTY session,
> that will result in multiple OMVS tasks being fork()ed or spawn()ed. Of
> late, such work has been failing with messages:
> IEW4000I FETCH FOR MODULE  FROM DDNAME SYS00061 FAILED BECAUSE
> INSUFFICIENT STORAGE WAS AVAILABLE.
> - and -
> CSV031I LIBRARY ACCESS FAILED FOR MODULE , RETURN CODE 14, REASON
> CODE 26110021, DDNAME SYS00061 which basically, as far as I can make out,
> mean that my region size is too small.
>
> But these are OMVS tasks, where a REGION size specification isn't allowed
> for.
> If I look at the type-30 records for the failing tasks, I see that the
> 'region requested' value is 54M in each case.
> We don 't have any SMFLIMxx member defined, so there's nothing coming from
> there, since that PARMLIB member *must* be defined if it is to be used -
> there are no defaults.
> Our IEFUSI is the default 'stub' supplied with the BCP i.e. all it does is
> the equivalent of a 'BR 14', so that isn't limiting anything either.
> So where is that 54M value coming from? How can I modify it?
>
> Regards
> Sean
>
> --
> 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
> ::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
>

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

Region size for OMVS tasks

[Sean Gleann]

We have a problem here that is proving to be … um... "resistant to
analysis" & I wonder if anyone on this list might be able to help.

Most of our developers submit work to the system from a PuTTY session, that
will result in multiple OMVS tasks being fork()ed or spawn()ed. Of late,
such work has been failing with messages:
IEW4000I FETCH FOR MODULE  FROM DDNAME SYS00061 FAILED BECAUSE
INSUFFICIENT STORAGE WAS AVAILABLE.
- and -
CSV031I LIBRARY ACCESS FAILED FOR MODULE , RETURN CODE 14, REASON
CODE 26110021, DDNAME SYS00061
which basically, as far as I can make out, mean that my region size is too
small.

But these are OMVS tasks, where a REGION size specification isn't allowed
for.
If I look at the type-30 records for the failing tasks, I see that the
'region requested' value is 54M in each case.
We don 't have any SMFLIMxx member defined, so there's nothing coming from
there, since that PARMLIB member *must* be defined if it is to be used -
there are no defaults.
Our IEFUSI is the default 'stub' supplied with the BCP i.e. all it does is
the equivalent of a 'BR 14', so that isn't limiting anything either.
So where is that 54M value coming from? How can I modify it?

Regards
Sean

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

Re: Anyone using cron?

[Sean Gleann]

Kees
THANK YOU!
Such a simple solution & one that I had not spotted despite all RTFMing
I've done.
When I do a '£T A,ALL' I can see the '24.05' & '24.10' time stamps, but I
never made the connection - just thought it was a weird way of specifying
time in the hour after midnight

Sean

On Tue, 6 Nov 2018 at 09:23, Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> The problem is that when you issue the automatic command with a time in
> the past, it will be issued immediately.
> You can avoid this by scheduling it for the next day with T=24.05. T= is
> calculated from the last midnight, so 24.05 means 00:05 tomorrow morning.
>
> Kees.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Sean Gleann
> > Sent: 06 November, 2018 9:49
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Anyone using cron?
> >
> > Hello all
> >
> > I have a need to run a couple of batch jobstreams at the same time every
> > day.
> > The streams are fully developed and they run happily at the required
> > time(s), under control of a couple of JES 'TA' automatic commands:
> > £ T A0001,I=86400,T=00.05,'£VS,''S JOB,N=DLYWORK1'''
> > £ T A0002,I=86400,T=00.10,'£VS,''S JOB,N=DLYWORK2'''
> > ('JOB' is an IEBGENER that copies files to the internal reader)
> > The trouble with that solution is that TA commands are obeyed both at
> > the
> > prescribed times AND at IPL (or JES start?) time.
> > Given that I'm currently working on commissioning a new production
> > system, IPLs are still fairly frequent, and so the timed jobstreams keep
> > resulting in 'unexpected' results.
> >
> > There isn't any cash in the kitty for something like OPC (now Tivoli?)
> > or
> > CA-7, and I've been unable to track down any 'freeware' batch job
> > scheduler
> > (though I'd be happy to be shown the error of my ways on that), so I
> > decided to try using cron instead.
> >
> > Is anybody using cron in this way? Is there anything I should beware of?
> >
> > Sean
> >
> >  .
> >
> > --
> > 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
>

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

Anyone using cron?

[Sean Gleann]

Hello all

I have a need to run a couple of batch jobstreams at the same time every
day.
The streams are fully developed and they run happily at the required
time(s), under control of a couple of JES 'TA' automatic commands:
£ T A0001,I=86400,T=00.05,'£VS,''S JOB,N=DLYWORK1'''
£ T A0002,I=86400,T=00.10,'£VS,''S JOB,N=DLYWORK2'''
('JOB' is an IEBGENER that copies files to the internal reader)
The trouble with that solution is that TA commands are obeyed both at the
prescribed times AND at IPL (or JES start?) time.
Given that I'm currently working on commissioning a new production
system, IPLs are still fairly frequent, and so the timed jobstreams keep
resulting in 'unexpected' results.

There isn't any cash in the kitty for something like OPC (now Tivoli?) or
CA-7, and I've been unable to track down any 'freeware' batch job scheduler
(though I'd be happy to be shown the error of my ways on that), so I
decided to try using cron instead.

Is anybody using cron in this way? Is there anything I should beware of?

Sean

 .

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

Accounting for OMVS-based work

[Sean Gleann]

I wonder if anyone may be able to provide some pointers on my latest
investigation...

Our developers log on to the system via a PuTTY window which provides a
tunnelled connection to SSH - they very rarely log on to TSO.

Having logged on, they issue UNIX commands that initiate OMVS task(s) which
in turn may spawn further OMVS tasks and/or submit batch jobs. Those
spawned tasks and batch jobs may themselves cause the creation of further
tasks and jobs, etc. The name of the batch job(s) is formed by appending a
single digit to user's logon id.
Having issued his initial command, our erstwhile developer is more-or-less
forced to wait until the entire chain of tasks - a 'unit of work', for want
of a better term - is complete, before he can study the results.
Alternatively, he may elect to log on again through another PuTTY window
and set off yet another such 'unit of work'.

I want to be able to summarise resource consumption along with elapsed time
for each of these units-of-work.


My latest efforts are centred around using the data in the OMVS segments of
SMF type-30 subtype 4 records, and trying to chase down the OMVS PID and
parent PID values. The recursive nature of such 'chains' of records is
proving to be a difficult nut to crack, and I'm wondering if I'm
approaching the problem from the right direction.

It may well be that such an analysis tool already exists and I'm
re-inventing the wheel.

The whole job must be done in-house with using the current software
portfolio. The idea of buying in new software will not be sanctioned by
TPTB - even using some bit of freeware will be viewed with suspicion.

If anyone can offer guidance or further information, I'd really like to
hear it.

TIA
Sean

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