As far as I’m aware there’s no IBM redbook that exclusively covers z/OS AT-TLS,
but there are several redbooks that contain relevant chapters or sections. See
this page for an index:
Hi Paul,
Is there a more friendlier name for this - "Advanced TS Migrations VTS built on
Dell power edge servers … 3480, 3490, and 3590 support"?
OP, in addition to Luminex, you can consider -
Optica zVT
BMC Model9 (called AMI Ops something these days)
Visara
I don't believe there's a small
Yes … Advanced TS Migrations VTS built on Dell power edge servers … 3480, 3490,
and 3590 support. AES256 and zSTD compressed images and smart support for
replication up to 8 locations, as well as scratch retention for any duration
site chooses.
I have a client that in the early stages of planning an AT-TLS installation for
TLS 1. Is there a Redbook that focuses on AT-TLS?
Thanks
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
Hello list,
We currently have a very small TS7760 grid, one frame at our primary site
replicating to a secondary frame at out alternate site. The alternate site is
a TS7760T with an old single frame TS3584 with 5 3592-E08 drives hanging off
the back of it. We just found out the 3584 is out
at 2.5 I think IBM ISPF changed the member delete to delete the member and
all generations so a PDSE wouldn't have been helpful at that point.
glad you had a backup available.
On Thu, May 9, 2024 at 3:03 PM Thomas Berg <
0619bfe39560-dmarc-requ...@listserv.ua.edu> wrote:
> I did the delete
I did the delete in ISPF 3.1. By some reason the space was released so only
1 track was left. I tried with PDS86 but it didn't find any member.
We found a decently fresh backup so I only lost 2 days of work. That was
acceptable.
Thomas Berg
Den tors 9 maj 2024 17:22Seymour J Metz skrev:
>
Well my mind isn't so great - as it never even thought about that. Thanks.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Phil Smith III
Sent: Thursday, May 9, 2024 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: JOB card format
GMTA!
GMTA!
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Mike Schwab
Sent: Thursday, May 9, 2024 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: JOB card format
357912 so 5x the 64k limit.
* 60 = 2,1474,720 seconds.
About 1/1000 of a 2GB limit if .001
Rex Pommier wrote, in part:
>So how did they come up with this one? From the JCL reference manual:
>minutes
>Specifies the maximum number of minutes the step can use the processor.
>Minutes must be a >number from 0 through 357912 (248.55 days).
>357912 minutes? My brain isn't coming up with a
357912 so 5x the 64k limit.
* 60 = 2,1474,720 seconds.
About 1/1000 of a 2GB limit if .001 second units.
On Thu, May 9, 2024 at 12:48 PM Pommier, Rex wrote:
>
> Subject: [EXTERNAL] Re: JOB card format
>
> On Thu, 9 May 2024 10:44:10 -0500, Steve Beaver wrote:
>
> >TIME=1440 turns off the
It is most definitely CPU time:
Job card on my test job:
//RRPJ#180 JOB (435001),'RRP',MSGLEVEL=(1,1),
// CLASS=T,MSGCLASS=X,TIME=(0,30),
// NOTIFY=
Abend info:
-STEPNAME PROCSTEPRC EXCP CONN TCB SRB CLOCK
-APPLYSMP
Is there a way to swap?
Actually, you can edit the old generation and save it which will create a new
base (generation 0) member and the original base will become the -1 generation.
That's about the best you can do.
With PDSEGEN you can compare any generation to any generation if that helps.
On Thu, 9 May 2024 10:11:35 -0500, Lionel B. Dyck wrote:
>It actually depends on how the member was deleted - sadly many tools will only
>delete the base (generation 0) member and leave the non-zero generations
>alone. However if that is the case then you need a tool that can display those
In TUs?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on behalf of
Pommier, Rex
Sent: Thursday, May 9, 2024 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
is to large if it's stored in timer units. If that isn't an anachronism, I
don't know what is.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on
Bletch! Where is that documented?
I find the suspension of JWT by TIME=1440 to not only unintuitive but harmful.
what if I need to limit the CPU time but allow long waits?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
Subject: [EXTERNAL] Re: JOB card format
On Thu, 9 May 2024 10:44:10 -0500, Steve Beaver wrote:
>TIME=1440 turns off the timing -- This depends on whether there is an
>exit controlling the use of 1440
>
I wonder why the designers didn't choose , the largest possible 4-digit
value, to
I don't know a Hebrew idiom for that.
An approximate English equivalent for לא דובים ולא יער would be There ain't no
such animal.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM
On Thu, 9 May 2024 17:06:01 +, Seymour J Metz wrote:
>לא דובים ולא יער
>
"not my monkeys, not my circus"?
>TIME= on the JOB and EXEC is, was and always will be CPU time. It's the TIME=
>on the /*JOBPARM that is wall clock time.
--
gil
On Thu, 9 May 2024 09:25:58 -0400, Phil Smith III wrote:
>...
>Thanks for the info, Shmuel et al. And yes, Gil, they're still card images,
>right?
>
Well, sort of. Alas, too many programmers and products remain unaware
that the 80-column limit was relaxed long ago, although larger valuew
Except that TIME=1440 or TIME=NOLIMIT unintuitively overrides that /*JOBPARM
value, right?
Not that I think IBM has the infodev resources to spend, but the amount of
discussion this generated suggests to me that the doc is insufficient.
-Original Message-
From: IBM Mainframe
On Thu, 9 May 2024 10:44:10 -0500, Steve Beaver wrote:
>TIME=1440 turns off the timing -- This depends on whether there is an exit
>controlling the use of 1440
>
I wonder why the designers didn't choose , the largest possible 4-digit
value,
to mean "forever"? (OTHH, I get cognitive
לא דובים ולא יער
TIME= on the JOB and EXEC is, was and always will be CPU time. It's the TIME=
on the /*JOBPARM that is wall clock time.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From:
Yes, it is CPU time.
Wall time is JWT specified in SMFPRMxx.
BTW: JWT is quite good for checking the above.
Simply run IEBGENER with SYSUT2 pointing to VOL=SER=NOSUCH and specify
TIME=(,10).
A little bit harder is to specify low service class (low velocity) and
run some ineffective I/O like
Yes, it is CPU time.
Wall time is JWT specified in SMFPRMxx.
BTW: JWT is quite good for checking the above.
Simply run IEBGENER with SYSUT2 pointing to VOL=SER=NOSUCH and specify
TIME=(,10).
A little bit harder is to specify low service class (low velocity) and
run some ineffective I/O like
Are you certain?
"minutes Specifies the maximum number of minutes a job may use the processor."
Seems to pretty clearly say processor (CPU) time.
Charles
On Thu, 9 May 2024 15:35:54 +, Hayim Sokolsky
wrote:
>In truth, TIME= is “wall time” and not CPU time. How many real-world minutes
TIME=1440 turns off the timing -- This depends on whether there is an exit
controlling the use of 1440
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Hayim Sokolsky
Sent: Thursday, May 9, 2024 10:36 AM
To:
In truth, TIME= is “wall time” and not CPU time. How many real-world minutes is
your job allowed to run before it gets cancelled if it runs over.
As there are 1,440 minutes in a 24 hour day, TIME=1440 turns off the timing.
Hayim
Hayim Sokolsky (he/him/his)
Director, Software Engineering
Alas, if he did a fast bulk erase then they're toast. That's also true for PDS.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on behalf of Tom
Marchant
It actually depends on how the member was deleted - sadly many tools will only
delete the base (generation 0) member and leave the non-zero generations alone.
However if that is the case then you need a tool that can display those
non-zero generations as, once again, many tools will ignore them
I believe PDSE member generations won't help if the member was deleted.
--
Tom Marchant
On Thu, 9 May 2024 11:58:59 +, Seymour J Metz wrote:
>For PDS: PDS96
>
>For PDSE: define it with multiple versions
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>עַם יִשְׂרָאֵל חַי
Hah, "your shop". We're a dev shop, three people, ADCD. Can't even spell
"accounting field for JES2", since we don't go near anything where that would
matter.
Thanks for the info, Shmuel et al. And yes, Gil, they're still card images,
right?
-Original Message-
From: IBM Mainframe
Thanks.
Unfortunately by some reason the space was released after the deletion
(used ISPF 3.1) so it didn't work. But we found a decently fresh backup and
could restore most members. Those I created yesterday and today was lost
but that's acceptable.
Note to myself and other people as hasty as
The generic format is in JCL Reference, but your installation may have imposed
restrictions on the accounting and programmer name fields.
Is your shop using the accounting field for JES2? If so, that's also in the JCL
reference. Or has IBM dropped that option?
--
Shmuel (Seymour J.) Metz
Classification: Confidential
JES2 ESTTIME parameter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Phil Smith III
Sent: Wednesday, May 8, 2024 7:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JOB card format
[CAUTION: This Email is from outside the Organization.
There are three distinct limits:
CPU time: controlled by JCL
Execution time limit: controlled by JECL.
Wait time limit: JCL only controls on/off.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
For PDS: PDS96
For PDSE: define it with multiple versions
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on behalf of
PDS is one of the tools that I really miss when I'm somewhere it's not allowed.
Essential, IMHO.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on behalf
If the PDS was a PDS then if you, or the system, hasn't performed a compress
you should be good. If it was a PDSE then you're toast (sorry).
If a PDS then get the PDS command from CBTTape file 182.
This command in PDS will restore all members - unfortunately it can't recover
the original
On Wed, 8 May 2024, at 13:17, Jason Cai wrote:
> Dear all
>
> I am reaching out to discuss a specific operation we are considering
> for our z/OS DCOLLECT reports. Currently, we are planning to delete all
> the datasets where LASTREF=NONE and DSORG=PS.
Multiple people have mentioned JCL but
I always use names (variables, modules, etc.) which cannot be confused
with any keyword.
Just to eliminate risk of problems as described here.
Sometimes I screw up with using "quick and dirty" scripts names of
variables which are as self-explanable as "r1, r2, x, y, i". :-(
--
Radoslaw
42 matches
Mail list logo
