you right! just oversight "4" IEFC662I INVALID LABEL, thank you too.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
In the future, you can easily help yourself by looking at the JCL expansion
which has statement numbers and formatted output. The error message points you
to the specific statement in error.
Jon.
On Saturday, October 5, 2019, 04:11:24 PM PDT, Rich Tabor
wrote:
//Val1 label has
Yes, everything's been setup, and I see SMF Type 2 records in the offloaded SMF
data from the logstream.
Mark Jacobs
Sent from ProtonMail, Swiss-based encrypted email.
GPG Public Key -
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
‐‐‐ Original Message ‐‐‐
On
Oops thanks!!!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
//Val1 label has lower case letters
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Lee
Sent: Saturday, October 5, 2019 3:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] BPXBATCH getting unexptected msg: INVALID LABEL
Dear,
when running a simple
Dear,
when running a simple BPXBATCH with //STDPARM DD, get an error INVALID LABEL,
which is nothing else that looks like a reference to a LABEL.
the Step releasing is below:
//Val1 EXEC PGM=BPXBATCH,REGION=0M,TIME=NOLIMIT
//*COND=(0,LT)
//*
//STDPARM DD *
sh cd
Since no one else is answering this, I'll make a really wild guess without any
real substance. I can't believe that IBM would default to SMF Signature
Validation enabled. Are there supposed to be SMF parm changes? Did you meet the
software and hardware requirements for this feature?
Jon.
On Saturday, October 5, 2019, 09:37:54 AM PDT, Jesse 1 Robinson
wrote:
> If you have a handful of users you can't cancel, use FORCE U=. It's
> messy, but the pain will (most likely) be short lived.
Use FORCE with great caution and realize that you could damage something or
require
Jon, I did not ask the original question but FWIW no SMF exit gets driven for a
QSAM/BSAM/BPAM OPEN, so there is no getting the current TOD.
Also OPEN time could be one, two, three or more days before CLOSE time. Date is
the most significant digits of time. A timestamp without a date is like a
On Saturday, October 5, 2019, 01:44:14 AM PDT, ITschak Mugzach
wrote:
>You can't. Instead of rename, allocate a new one, copy into the current one
> and update the tso proc with the new name. A they later you'll be able to
> delete the old one.
If this is a non-sms dataset, then you can
On Saturday, October 5, 2019, 08:53:07 AM PDT, Charles Mills
wrote:
> I was assuming (yes, I know) that the OP wanted realtime notification of the
> OPEN,
> based on the mention of exits.
> If not, SMF14OPE is pretty good. It gives the time but not the date, which is
> kind of half an
What exactly is the question here? Where did the idea of SSI calls 16 and
17 in the subject come from? Are you saying that there are function codes
16 and 17 being issued but you just have no documentation on them? Have you
intercepted 16 and 17 calls? IBM seems to be quite definite in their
On Wednesday, October 2, 2019, 12:52:56 PM PDT, Kirk Wolf wrote:
> You really like all of this mangling of the shell syntax?
In all Unix systems, we simply avoid situations where this mangling is needed
(e.g. "sh -c some-mangled-statements"). Why do you think this a good practice
in BPXBATCH
John,
Yes, that is the correct control statements to scratch the tape (assumption
being that it is not an EDM tape).
Russell Witt
Broadcom
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John Dawes
Sent: Friday, October 4, 2019
On Sat, 5 Oct 2019 16:37:43 +, Jesse 1 Robinson wrote:
>Depending on the size or your shop and the number of TSO users, you could
>cause a FUBAR by renaming any shared ISPF data set. Those get allocated not
>only through logon PROCs but also through any number of CLIST/REXX over which
>you
Depending on the size or your shop and the number of TSO users, you could cause
a FUBAR by renaming any shared ISPF data set. Those get allocated not only
through logon PROCs but also through any number of CLIST/REXX over which you
may have zero control or even knowledge. However you do this,
Sorry that this got side tracked.
My point was that we have language environments (not just standalone
languages). HTML, Javascript and CSS are combined in web browsers to become a
single language environment. As an example, the early implementation of C++ was
developed as an extension to C
So using your normal change control process, the following steps can be taken
1) Issue D GRS,RES=(*,data-set-name-here)
See who has it allocated
2) Set TSO USERMAX to 0. F TSO,USERMAX=0
Make sure you are logged on before you issue this command
3) Start to cancel
On Tuesday, October 1, 2019, 10:45:59 AM PDT, Charles Mills
wrote:
> #ifdef __MVS__
> #define OVERRIDE
> #else
> #define OVERRIDE override
>#endif
#if directives are not valid in C macro's. C macro's only copy information.
This example simply shows that C macro's content can be changed.
I was assuming (yes, I know) that the OP wanted realtime notification of the
OPEN, based on the mention of exits. (Or perhaps I assumed that because I had
been working on realtime security auditing for the past nine years.)
If not, SMF14OPE is pretty good. It gives the time but not the date,
Have you looked at exit IFG0EX0B ?
Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
Web: www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: 05
I have one tso session running but the user is not "online". I tried cancelling
it but the session isnt going away.
Bill
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu
you beat me to send :)
Joe
On Sat, Oct 5, 2019 at 3:44 AM ITschak Mugzach wrote:
> You can't. Instead of rename, allocate a new one, copy into the current one
> and update the tso proc with the new name. A they later you'll be able to
> delete the old one.
>
> בתאריך שבת, 5 באוק׳ 2019, 11:39,
You can't. Instead of rename, allocate a new one, copy into the current one
and update the tso proc with the new name. A they later you'll be able to
delete the old one.
בתאריך שבת, 5 באוק׳ 2019, 11:39, מאת Bill Giannelli <
billgianne...@gmail.com>:
> I am trying to rename a CLIST library
I am trying to rename a CLIST library allocated to users for ISPF. how do I
force users to deallocate the dataset so I can rename it? I have been sending
tso messages but more users keep allocating it.
thanks
Bill
--
For
25 matches
Mail list logo
