I have a client with an existing old z/OS V1.4 system that has COBOL-II at
version 1.4 (5668-958), but the other person was correct that most programs
will compile under the current versions of COBOL.
Brian
--
For IBM-MAIN
> You cited TWO sentences
Yes, I cited two consecutive sentences, to provide context.. Why are you
ignoring the sentence directly prior my response?
> Can it be shorter and more ambigous?
It's not ambiguous at all. Had it been a response to the first sentence then it
would have directly
I believe that 3120 is one of the optimal block sizes for 80 byte records on
3330. At 3120 you get four blocks/track, at 3200 you get only three.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List
W dniu 20.01.2021 o 20:35, Seymour J Metz pisze:
Whoosh! What is in dispute is the ludicrous claim '"Illegal" from SMP/E point
of view'. Aps have *never* been Illegal from SMP/E point of view, or even from the POV
of the free SMP versions.
--
Shmuel (Seymour J.) Metz
Whoosh! What is in dispute is the ludicrous claim '"Illegal" from SMP/E point
of view'. Aps have *never* been Illegal from SMP/E point of view, or even from
the POV of the free SMP versions.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
On Wed, 20 Jan 2021 13:13:44 -0500, David Spiegel wrote:
>"... Formerly some utilities (Linkage Editor?) imposed a limit of 3120. ..."
>Linkage Editor //SYSLIN had a Max BLKSIZE of 3200.
>
I stand corrected.
Damn! So I was needlessly using 3120 all those years.
It's mentioned (in an example)
Greetings,
A gentle reminder that the next meeting of the GSE UK Security Working Group,
will take place on Thursday 4th February 2021 via Zoom – sessions will run from
09:00 to 18:45 GMT (UK time). This meeting is free to attend and is open to
both GSE member companies and non-members.
The
Not sure what the argument is about here, whether you can zap a SMPE module, or
whether you *should* zap a SMPE module. We used to have this usermod for Fault
Analyzer before it was a dynamic exit
++USERMOD (MSYS013) .
++VER(Z038) FMID(HBB77A0) .
"... Formerly some utilities (Linkage Editor?) imposed a limit of 3120. ..."
Linkage Editor //SYSLIN had a Max BLKSIZE of 3200.
On 2021-01-20 11:25, Paul Gilmartin wrote:
On Wed, 20 Jan 2021 10:03:01 -0600, Wendell Lovewell wrote:
Could you please elaborate on your comment "never solved issue
W dniu 20.01.2021 o 18:43, Seymour J Metz pisze:
Nonsense, there's nothing illegal about ++ ZAP.
SMP does what you would expect, including warning you of conflicting service.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe
Nonsense, there's nothing illegal about ++ ZAP.
SMP does what you would expect, including warning you of conflicting service.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
I'm not aware of one; do XMIT and RECEIVE accept SYSOUT(), or prompt you for a
class?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin
On Wed, 20 Jan 2021 17:15:26 +, Seymour J Metz wrote:
> > Would it be proper first to do BPXWDYN( INFO SYSPRINT ... )
>> and finally restore it to its initial state in case it hadn't been DSN(*)?
>
>Yes, but if you use the SYSOUT keyword then you don't need to reallocate
>SYSPRINT in the
W dniu 20.01.2021 o 18:10, Seymour J Metz pisze:
There are ZAPs to change it in original IBM code.
"Illegal" from SMP/E point of view
No.
Yes.
--
Radoslaw Skorupka
Lodz, Poland
==
Jeśli nie jesteś adresatem tej
> Would it be proper first to do BPXWDYN( INFO SYSPRINT ... )
> and finally restore it to its initial state in case it hadn't been DSN(*)?
Yes, but if you use the SYSOUT keyword then you don't need to reallocate
SYSPRINT in the first place.
> Is it necessary to CLOSE a file before REUSing it?
> There are ZAPs to change it in original IBM code.
> "Illegal" from SMP/E point of view
No.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
R.S.
On Wed, 20 Jan 2021 10:03:01 -0600, Wendell Lovewell wrote:
>
>Could you please elaborate on your comment "never solved issue like non-SDB
>(system determined blocksize) in XMIT and RECEIVE command"?
>
Long ago there were discussions here of ISPF SUBMIT's failing because
of inadequate (default?)
Hi Dave,
Yes...I do tend to let topics move along until I feel I need to stumble in :).
There is absolutely no doubt that the security for z/OSMF is the toughest part
to get working. I would like to suggest trying out the Security Configuration
Assistant, which was meant to help with that. It
W dniu 20.01.2021 o 17:03, Wendell Lovewell pisze:
Radoslaw,
Could you please elaborate on your comment "never solved issue like non-SDB (system
determined blocksize) in XMIT and RECEIVE command"?
I have been having an issue with TSO RECEIVE (and a program that also calls IEBCOPY) when
SDB
I just ran a quick test thus:
xmit x.y ds(test.pdse) outds(test.xmit) sysout(x)
And the IEBCOPY messages were NOT displayed on the terminal but can be found
using (E)JES or SDSF or ... under my userid in the spool.
Does that satisfy the OP's request?
Lionel B. Dyck <
Website:
On 1/20/2021 7:03 AM, Peter Relson wrote:
That's the control I was thinking of. Some sites might set to an output
class that is the 'bit bucket', i.e. a JES2 output class that specifies
OUTPUT=DUMMY, and then you won't get any of the msgs (but won't have the
option that Greg's approach provides
On Wed, 20 Jan 2021 05:43:20 -0500, David Spiegel wrote:
>
>ALLOC F(SYSPRINT) DA(DUMMY) REU
>XMIT ...
>ALLOC F(SYSPRINT) DA(*) REU
>
Would it be proper first to do BPXWDYN( INFO SYSPRINT ... )
and finally restore it to its initial state in case it hadn't been DSN(*)?
(DISP(MOD) if it had been a
Radoslaw,
Could you please elaborate on your comment "never solved issue like non-SDB
(system determined blocksize) in XMIT and RECEIVE command"?
I have been having an issue with TSO RECEIVE (and a program that also calls
IEBCOPY) when SDB is "Y". IEBCOPY is having some sort of problem and
Greg Price wrote
What is PARMLIB->IKJTSOnn->TRANSREC->SYSOUT set to?
Default of * goes to terminal.
We use X which is a HELD SYSOUT class, so you can look at it later if
there is a glitch, or ignore it if no problem.
That's the control I was thinking of. Some sites might set to an output
Or: TSO XMIT SYSOUT(x)
No need for special allocations.
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:
How about running in batch?
//X010EXEC PGM=IKJEFT1A
//SYSTSPRT DD SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=dsn.tobe.xmited
//SYSUT2 DD DISP=(NEW,CATLG,DELETE),UNIT=SYSDA,BLKSIZE=0,
//
On Tue, 19 Jan 2021 11:40:34 -0600, John Ganci wrote:
>In order to see how z390 handles the signs, a short program that does some
>divisions for (dividend,divisor) pairs having signs A,B,C,D (16 combinations)
>was run on z390. Partial results:
Why not post your test program code iso. of the
Thank you everyone for your answers.
It seems I can redirect SYSOUT to DD DUMMY for a while.
In fact I wanted to switch off IEBCOPY reporting, AFAIR it was LIST=NO.
It can be specified in PARM field or as an optional parameter of COPY
command in SYSIN.
It is not exactly the same as whole sysout
Hi Paul
ALLOC F(SYSPRINT) DA(DUMMY) REU
XMIT ...
ALLOC F(SYSPRINT) DA(*) REU
Regards,
David
On 2021-01-19 21:29, Jesse 1 Robinson wrote:
The messages issued during TSO TRANSMIT are actually coming from IEBCOPY. By
custom in most shops, DD SYSPRINT is commonly allocated to the terminal, i.e.
Concurrently: DISP=OLD While technically it will not suppress the start, it
will prevent it from running.
During the life of the SYSPLEX? I guess it could rename its own member in
PROCLIB to something else. And use some kind of shutdown process to rename it
back.
On Wed, 20 Jan 2021 12:58:16
Hello
Is there any configuration or any method to suppress starting the same
started task Twice in zOS ?
We are having zOS 2.2
Peter
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
31 matches
Mail list logo
