You assign the volume label with ICKDSF. If you init two+ different
devices with the same volser and the default for both+ is to be online
you will get this message. Since these addresses are quite a bit
apart, is one production and one a DR test? If so the Production
system should set the
Your research is correct. The system is working as designed. Duplicate volumes
with the same VOLSER are not allowed to be online at the same time, so it's
asking the operator which one needs to be online. As far as your question why
are there duplicates, that answer needs to be ascertained from
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikja300/cmdhost.htm
Allows z/OS REXX to call various environments and execute their commands.
On Thu, Nov 19, 2020 at 2:03 PM Jesse 1 Robinson
wrote:
>
> Oops. I meant ' TSO/CLIST capabilities'.
>
> -Original
Dear,
These messages come out at the time of IPL in past few IPL cycle;
IEA213A DUPLICATE VOLUME 'RP@C03' FOUND ON DEVICES 3404 AND 4802.
IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE
IEA213A DUPLICATE VOLUME 'RP@C04' FOUND ON DEVICES 3405 AND 4803.
IEA213A REPLY DEVICE NUMBER WHICH IS
Why are you so easily offended? Why don't you think that accuracy matters?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent:
On Fri, 20 Nov 2020 12:42:34 +1100, Robin Vowels wrote:
>On 2020-11-20 12:32, Paul Gilmartin wrote:
>> jn:
>> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.hasc300/has2z1_Use_of_unblocked_records_for_SYSIN_and_SYSOUT_data_sets.htm
>>
>> You should not block
On Fri, 20 Nov 2020 00:10:14 +, Seymour J Metz wrote:
>UNIT=INTRDR is not valid in JES2, and the internal reader is very much alive
>and well. It does not present a security issue, and bog standard users can
>exploit it freely.
>
Why do you so often feel it's necessary to state a snarky
On 2020-11-20 12:32, Paul Gilmartin wrote:
jn:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.hasc300/has2z1_Use_of_unblocked_records_for_SYSIN_and_SYSOUT_data_sets.htm
You should not block SYSIN and SYSOUT data sets because the SAM
(sequential access
Me Thinks I need IARV64 REQUEST=GETSHARED
If I am getting the cell in a different address space then where the IARV64
was issued
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
Same experience. No idea. The IBM Cloud.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Thursday, November 19, 2020 5:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: any one know what wrong with the IBM
jn:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.hasc300/has2z1_Use_of_unblocked_records_for_SYSIN_and_SYSOUT_data_sets.htm
You should not block SYSIN and SYSOUT data sets because the SAM
(sequential access method) compatibility interface will increase
ObSchiller "Mit der Dummheit kämpfen Götter selbst vergebens"
Pistol. Foot.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of Tom
Brennan
Sent: Thursday, November 19, 2020 7:19 PM
To:
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Seems like it been down for a while
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AUTO is file 332 I believe.
Referenced here along with JES2 $TA commands.
http://www.longpelaexpertise.com/ezine/DoWeNeedAutomationSoftware.php
On Fri, Nov 20, 2020 at 8:14 AM R.S. wrote:
> W dniu 19.11.2020 o 21:46, Wayne Bickerdike pisze:
> > Charles,
> >
> > I like Bobby Herring's
It will not without a password
Sent from my iPhone
I promise you I can’t type or
Spell on any smartphone
> On Nov 19, 2020, at 18:12, Seymour J Metz wrote:
>
> Sure, but why do you think that specifying the userid will do them any good?
>
>
> --
> Shmuel (Seymour J.) Metz
>
Let's say the started task is setup as SURROGAT for multiple userids.
As one of those id's, if I am given access to the JCL I could submit a
job as if I was another one of those id's. No?
On 11/19/2020 4:12 PM, Seymour J Metz wrote:
Sure, but why do you think that specifying the userid will
Sure, but why do you think that specifying the userid will do them any good?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of Tom
Brennan
Sent: Thursday, November 19, 2020 2:16 PM
To:
I think I've got this. No error checking, but I think it is adequate for my
needs. I will add some error checking, such as for null parameters, where it
is convenient to do so. Here's the Rexx
Quote = '"'
Comma = ','
Parse Value Arg(1) with (Quote) First (Quote) (Comma) (Quote) Second (Quote)
UNIT=INTRDR is not valid in JES2, and the internal reader is very much alive
and well. It does not present a security issue, and bog standard users can
exploit it freely.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe
The REXX parse statement is not one of its strong points; certainly not in the
same league as, e.g., Perl.
There is an old XPARSE (sp?) package that interfaces REXX to IKJPARS; I wish
that IBM would provide a supported version, pre3ferably in a new REXX processor
incorporating ANSI and OOREXX
The terms "logical order" and visual order" should be applied to an entire line
of mixed-language text Take a look at Unicode bidi processing; it can get very
complicated.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe
IKJPARS has much more functionality than CLIST uses, e.g., it can syntax check
the values.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Jesse 1 Robinson
Sent: Thursday, November 19, 2020
> Also, even if you do make TSO REXX IKJPARS-capable, all you're doing
> is making REXX inconsistent across all the different subsystems that it's
> usable in.
Not even close; you're providing a useful facility fo a particular environment,
just as ADDRSS XEDIT or ADDRESS CONSOLE does. There is
There is an old REXX-callable package called something like XPARSE that uses
IKJPARSE.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Jesse 1 Robinson
Sent: Thursday, November 19, 2020 3:24
Thanks, yeah, that is the direction I think I am going. I am thinking of
using " " to delimit the quoted strings, and prohibiting embedded "s. The
use of " is not "traditional MVS" but it is close and I like it.
Then I think I should be able to parse using '"' as a delimiter with minimal
Charles, would something like this help? Now I used ( and ) to surround the
first two items and not a '. Not tested how you would do the whole ' thing.
SAY 'TESTPARS: Start REXX'
Parse Upper External TESTPRM
SAY 'Display
On Thu, 19 Nov 2020 20:24:25 +, Jesse 1 Robinson wrote:
>No argument. Still, it's hard to beat the flexibility of TSO/CLIST parameter
>handling. I wrote a TSO command once partly for kicks. Really complicated.
>Pointers to pointers to pointers. When it was done, it was super easy to use.
> very few people use command line TSO though?
I do, all the time. I don't "live" in command line TSO but looking at my PDS
of Rexx commands I see 75 of them (many of which I probably have not used in
years). I have commands to do specialized job submissions. I have commands
that do some
Thanks... and that might be the key. Then it ends up like we used to
run CA7 where application programmers created the JCL, but it was run
through a review process before being implemented. In the early days
the jobs all ran under the CA7 task's userid which had high access.
Later USER= was
Skinning a cat is certainly an idiom. Like most idioms, its origin is obscure
or even controversial--not so much the idea, but the history of the phrase. I
Googled it and delighted in the variations. For one,
"There's more than one way to skin a cat means there are many ways to do
something,
On Thu, 19 Nov 2020 11:21:17 -0800, Charles Mills wrote:
>Yes indeed, if an unwashed user can update the member passed to RDR then all
>bets are off.
>
There's an implied argument here supporting the crontab; /bin/submit
approach: such unwashed users might be loath to further dirty their
hands
W dniu 19.11.2020 o 22:13, David Spiegel pisze:
Hi Radek,
After I sent it, I realized that I addressed you incorrectly. Sorry.
No problem at all. I just suspected there is some meaning of such
sentence which I don't understand. Curiosity - that's all.
Regards
--
Radoslaw Skorupka
Lodz,
On Thu, 19 Nov 2020 15:48:41 -0500, David Spiegel wrote:
>
>"... That means your job may contain DD * statements, etc. ..."
>As of z/OS 1.13, Cataloged Procedures can have DD *
>
That's newly true likewise of inline Procedures. Either provides
a valuable ability to modify instream data sets as:
W dniu 19.11.2020 o 21:46, Wayne Bickerdike pisze:
Charles,
I like Bobby Herring's solution. We use similar commands combined with
automation at one customer.
AUTO is very, very easy to install.
It uses a PDS with this syntax : @2230
At 2230, it does whatever is in the member with a day
Hi Radek,
After I sent it, I realized that I addressed you incorrectly. Sorry.
Regards,
David
On 2020-11-19 16:09, R.S. wrote:
W dniu 19.11.2020 o 21:48, David Spiegel pisze:
Hi Skip,
"... That means your job may contain DD * statements, etc. ..."
As of z/OS 1.13, Cataloged Procedures can
On 19 Nov 2020 11:30:29 -0800, in bit.listserv.ibm-main
(Message-ID:<0b3b01d6beaa$60ee3530$22ca9f90$@mcn.org>)
charl...@mcn.org (Charles Mills) wrote:
>The issue I am struggling with is that for all of Rexx's
parsing power,
>which is of course legendary, it does not seem
well-suited to
W dniu 19.11.2020 o 21:48, David Spiegel pisze:
Hi Skip,
"... That means your job may contain DD * statements, etc. ..."
As of z/OS 1.13, Cataloged Procedures can have DD *
Yes, I wanted to say that as well, but simply forgot. There are also new
features in JCL since z/OS 2.1, which I didn't
Hi Skip,
"... That means your job may contain DD * statements, etc. ..."
As of z/OS 1.13, Cataloged Procedures can have DD *
Regards,
David
On 2020-11-19 15:23, R.S. wrote:
W dniu 19.11.2020 o 00:00, Charles Mills pisze:
Is there a JES2 command to submit a job from a PDS or PROCLIB, roughly
Charles,
I like Bobby Herring's solution. We use similar commands combined with
automation at one customer.
AUTO is very, very easy to install.
It uses a PDS with this syntax : @2230
At 2230, it does whatever is in the member with a day flag:
+1+2+
* MTWTF I SMF
There are apparently several ways to skin a cat. Are they documented anywhere?
Aside from the question of why do it, I've always wondered if the cat cares...
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
No argument. Still, it's hard to beat the flexibility of TSO/CLIST parameter
handling. I wrote a TSO command once partly for kicks. Really complicated.
Pointers to pointers to pointers. When it was done, it was super easy to use.
Sigh.
.
.
J.O.Skip Robinson
Southern California Edison Company
W dniu 19.11.2020 o 00:00, Charles Mills pisze:
Is there a JES2 command to submit a job from a PDS or PROCLIB, roughly
analogous to TSO SUBMIT?
I want to run a predefined job, unmodified, once a day. (No, I don't have a
real scheduler.) I figured I could do something with $T A,I=86400,'command'
Hmm... I can't recreate any case where I can run another user's program
without the full path having both r and x (didn't try it without r), regardless
of it being executed with just the full path or from a script with the full
path. I must have done something that I don't recall. Oh well.
On Thu, 19 Nov 2020, at 19:30, Charles Mills wrote:
> It would appear to be a lot of work, but it would seem that "TSO format
> command parsing" and Rexx would be a natural marriage.
>
> I have never used IKJPARS, so I don't claim to be an expert, and others
> might disagree.
Surely very few
Oops. I meant ' TSO/CLIST capabilities'.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Jesse 1 Robinson
Sent: Thursday, November 19, 2020 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Has anyone integrated Rexx with IKJPARS?
*** EXTERNAL EMAIL -
CLIST has pretty much the same parsing capabilities as TSO. I think that's
natural as both types of command processors were developed on the same
platform. REXX OTOH was imported to MVS from elsewhere--VM? I miss those
TSO/REXX capabilities.
I once encountered a 'REXX preamble' that provided
On 2020-11-19, at 06:58:36, Seymour J Metz wrote:
>
> It's not desktop versus mainframe, but rather a codepage issue. Some software
> on both PC and mainframes expects Hebrew in visual order. Any software
> supporting Unicode should process Hebrew text in logical order. But the OP
> did not
It would appear to be a lot of work, but it would seem that "TSO format
command parsing" and Rexx would be a natural marriage.
I have never used IKJPARS, so I don't claim to be an expert, and others
might disagree.
The issue I am struggling with is that for all of Rexx's parsing power,
which is
I'm not sure that I would give users access to update such JCL.
On 2020-11-19 14:13, Tom Brennan wrote:
So if the JCL dataset can be updated by the user and they decide to
remove the USER= parm, then the STC userid would get control. And in
that case the unique userid set up for that STC
Yeah, but, the STC Userid has to have SURROGAT to it, otherwise it fails.
On 2020-11-19 14:16, Tom Brennan wrote:
I just thought of one more problem with my scenario. If the JCL can
be updated by the user, then they could set USER= to whatever they
want, spoiling the idea of using a single
Yes indeed, if an unwashed user can update the member passed to RDR then all
bets are off.
I would guess that if anything the "STC userid" would likely have more access
than was desirable.
I am not proposing this as a universal solution; I am proposing it as MY
solution.
Charles
In article <0a3501d6be09$afb97b80$0f2c7280$@mcn.org>,
Charles Mills wrote:
> Right! I remember that. I remember that was how you ran anything. You
> started a real reader: it fired up the 2540 and read in the job. And then
> you did a S WTR (?) to print the output. OS/360 on a 360/40.
>
>
I just thought of one more problem with my scenario. If the JCL can be
updated by the user, then they could set USER= to whatever they want,
spoiling the idea of using a single STC for multiple users.
On 11/19/2020 11:13 AM, Tom Brennan wrote:
So if the JCL dataset can be updated by the user
So if the JCL dataset can be updated by the user and they decide to
remove the USER= parm, then the STC userid would get control. And in
that case the unique userid set up for that STC would have little access
and would likely fail on the first dataset.
Do I have that about right?
On
Hi Charles,
If you code all of my overrides, the problem of VOL=, DCB= etc. will be
bypassed and you will be able to use the RDR Cataloged Procedure forever.
Regards,
David
On 2020-11-19 14:02, Charles Mills wrote:
stuff coded that would work as is for pretty much no one
At least on this
Hi Skip,
"... the default SAF userid for STCs will be propagated to the submitted
job ..."
If the submitted job has a USER= on the Job Card and the RDR STC's
Userid has SURROGAT to all owner of SUBMIT'd Jobs, this is not a problem.
(I also would not give RDR the default STCID.)
Regards,
David
> stuff coded that would work as is for pretty much no one
At least on this system (which I inherited) IEFRDER specifies
UNIT=TAPE,DCB=BLKSIZE=80, and a hard-coded VOLSER. "Work for pretty much no
one" is overly optimistic!
I'm aware of the userid issue and think I can live with it. I suppose
You're right about the cyclical refresh of auto commands. Without some kind of
intervention, JES2 auto commands with T= will expire at midnight. So we
schedule an auto command for midnight to reinstate all auto commands. The
process is remarkably resilient. I recall only a handful of failures
We use a similar process. The supplied RDR proc is a bit clumsy with stuff
coded that would work as is for pretty much no one. So like many other shops,
ages ago we wrote our own version with customized data set and unit parameters.
The big problem with an RDR-like solution is that the default
We've also setup DIAGxx to automatically take a SAD and re-IPL if z/OS gets one
of the documented wait states. It does work as described. No operator
intervention needed.
Mark Jacobs
Sent from ProtonMail, Swiss-based encrypted email.
GPG Public Key -
Years ago we eliminated tape from the SADUMP process altogether. Also
eliminated operator intervention. For each LPAR, we have a LOAD (IPL) profile
that points to a DASD volume containing SAD IPL text. The SAD parameters run
the dump to DASD without prompting the operator at all. When the dump
Thanks.
> why not AUTO
Trying to keep things simple. Trying to avoid one more piece in the puzzle if
possible. Nothing whatsoever against AUTO specifically or the CBT tape in
general.
> issue SLEEP on schedule
Great idea. I will look into that.
> Self-perpetuating job, that submits itself
We have a rather simple solution we use.
We have this command in the JES commands member:
$TA,T=23.00,''$VS,S JOB,J=CLEANJES'''
That starts a started task called JOB. It is in a library that is in the JES
PROCLIB concatenation.
It looks like this:
//JOBPROC J=XXX,
Charles,
Why don't you grab a copy of AUTO from the CBT tape. It has a scheduler
function.
We use it on Dallas to schedule the SLEEP command after business hours to
save some costs.
We also have a schedule set up to do ADRDDSU backups and an offsite FTP.
You could also have a job that submits
On Thu, 19 Nov 2020, at 16:01, Dana Mitchell wrote:
> They are definitely different. And even within z/OS there will
> sometimes be a PTF that changes an internal structure such that it has
> an ACTION HOLD telling you that you need to recreate the SADUMP program
But the SADUMP program (at
On Thu, 19 Nov 2020, at 15:46, Rupert Reynolds wrote:
> Most people I mention it to are surprised, and they expect it keep running
> until a modiFy or stoP tells it otherwise.
A good example (if it still is?) of a STC that starts to do something and then
stops is/was SMFDUMP.
We used to use STCs
They are definitely different. And even within z/OS there will sometimes be a
PTF that changes an internal structure such that it has an ACTION HOLD telling
you that you need to recreate the SADUMP program
Dana
On Thu, 19 Nov 2020 10:09:07 -0500, Tony Thigpen wrote:
>This is a curiosity
It used to be common to issue a bogus START to force allocation processing. I
would be surprised if there weren't a lot of very short started tasks in use.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List
Most people I mention it to are surprised, and they expect it keep running
until a modiFy or stoP tells it otherwise.
That's the reason I mentioned it :-)
Roops
On Thu., Nov. 19, 2020, 14:22 Jeremy Nicoll,
wrote:
> On Thu, 19 Nov 2020, at 14:12, Rupert Reynolds wrote:
> > Off the cuff, I'm
Hi Charles,
If you are using the "stock" Cataloged Procedure, you will have to
include all of the "overrides" I specified.
Regards,
David
On 2020-11-19 10:34, Charles Mills wrote:
I was and am under control on the $TA part and fully intend to use that.
It's not the whole solution, though. My
As others have asked, what is "the usual"? Sometimes an STC ends almost
immediately after the START because of some error that is entirely local to the
STC, such as a bad parameter. z/OS does not seem to mind at all. >From z/OS's
point of view, an STC that generates an error message and then
Have you considered OMVS's CRON?
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Thursday, November 19, 2020 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there a JES2 command to submit a job?
[External Email. Exercise caution when
I was and am under control on the $TA part and fully intend to use that.
It's not the whole solution, though. My question was "what can the $TA
schedule that will run a job" and these replies have provided the answer.
The answer is something like
$T A,,86400,'$VS ''S RDR,DSN=MY.PDS(MYJOB)''
This is a curiosity question.
Is the SADUMP IPL tape the same when created by z/OS, z/VM or z/VSE?
Same question for a SADUMP DASD volume?
Tony Thigpen
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
Yes, you have been able to have a defaul UID and GID for lo these many years.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Unless you were really storage constrained, you started a writer and left it
running untill the next IPL. Also, MVT had something called an ASB Reader,
which ran at high speed in a small region, then ran a reader/interpreter from
the DASD file it created.
--
Shmuel (Seymour J.) Metz
There's almost nothing special about an STC; it's got essentially the same
environment as, e.g., APPC, ASCH, JOB, TSU. It has a userid, and its access is
limited to that for the userid.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From:
On Thu, 19 Nov 2020, at 14:12, Rupert Reynolds wrote:
> Off the cuff, I'm pretty sure it runs as an STC, but one that doesn't do
> the things you'd normally expect an STC to do.
There's nothing that an STC is "normally expected to do". Some run for
ages, but some don't. The significant point is
Off the cuff, I'm pretty sure it runs as an STC, but one that doesn't do
the things you'd normally expect an STC to do.
I don't know whether any versions of MVS and z/OS, or any automation, would
react to an "STC" ending without doing the usual, but I'd guess not.
I know MVS 3.8 (TK4-) accepts
ASSBISQN is not always the same as the ASTE Instance Number (ASTE rather
than STE).
Maybe the back-handed hint is that this is not something you should be
doing? I wouldn't go that far.
Architecturally, the ASTE instance number is in the ASTE.
Peter Relson
z/OS Core Technology Design
I finally woke up. The console used by CA-OPS/MVS is set in the
OCCONSOLENAME parameter. And the console specified in that is now
OFFLINE due to I/O errors. We won't fix it because "z/OS is going away."
So I need to change the name to one which is still working.
On Thu, Nov 19, 2020 at 6:58
It's not desktop versus mainframe, but rather a codepage issue. Some software
on both PC and mainframes expects Hebrew in visual order. Any software
supporting Unicode should process Hebrew text in logical order. But the OP did
not say which codepage he is using.
--
Shmuel (Seymour J.) Metz
Which EBCDIC code page are you using? What parameters do you have on xmitip?
You may have to do the translation yourself and send the data as binary.
iC
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on
On 2020-11-19, at 01:39:45, Gadi Ben-Avi wrote:
>
> The answer depends on what SMTP server you are running on z/OS.
> Is it SMTP or CSSMTP.
>
Does either of these, or TXT2PDF, avoid problems resulting
because (as I understand) z/OS stores Hebrew text backwards
while desktop systems expect it
On Thu, Nov 19, 2020 at 7:17 AM Seymour J Metz wrote:
>
>
> SYSLOG is not a console, nor is OPERLOG. You could direct the output to an
> out of line area, e.g., L=A, if you have one.
>
> Does that console have MAStER authority?
>
Yes. All consoles have MASTER authority. There are only two
Nit: both are SMTP clients. An SMTP server receives jobs via SMTP.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Gadi Ben-Avi
Sent: Thursday, November 19, 2020 3:39 AM
To:
If you have a card reader and you start RDR with the address of a card reader
then it submits jobs from that cards reader. Subject to security, you can read
from any dataset as long as it supports FB80.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
SYSLOG is not a console, nor is OPERLOG. You could direct the output to an out
of line area, e.g., L=A, if you have one.
Does that console have MAStER authority?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion
STC.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, November 19, 2020 8:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
On Thu, 19 Nov 2020 11:04:32 +, Rupert Reynolds wrote:
>
>//MYJOB DD SYSOUT=(A,INTRDR)
>looks like a. In fact I've used that from TSO, lthough I can't remember
>whether the ALLOC command hndles INTRDR, or whether I used SVC 99.
>
WRITER(INTRDR)
Likewise for BPXWDYN.
>If the job can
On Wed, Nov 18, 2020 at 6:20 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 18 Nov 2020 17:39:33 -0600, John McKown wrote:
>
> > most z/OS people
> >are still fairly ignorant of z/OS UNIX and are reluctant to use it. A
> few
> >years ago I had another
I know that I can direct the output of a command, such as DISPLAY, to a
specific console using something like D A,L,L=consname . But is there a way
to direct it only to SYSLOG? I have a CA-OPS/MVS message rule which issues
a DISPLAY command. I had to put a L=specific_console because I got the
Ah yes
//MYJOB DD SYSOUT=(A,INTRDR)
looks like a. In fact I've used that from TSO, lthough I can't remember
whether the ALLOC command hndles INTRDR, or whether I used SVC 99.
If the job can justifiably be in something like SYS1.PROCLIB, it's even
easier.
S MYJOB :-)
Roops
On Thu., Nov. 19,
On Thu, 19 Nov 2020, at 00:19, Charles Mills wrote:
> Right! I remember that. I remember that was how you ran anything. You
> started a real reader: it fired up the 2540 and read in the job. And
> then you did a S WTR (?) to print the output. OS/360 on a 360/40.
But the S RDR... command doesn't
The answer depends on what SMTP server you are running on z/OS.
Is it SMTP or CSSMTP.
For SMTP I think you need to have a file named TCPIPPFX.STANDARD.TCPXLBIN with
the correct translation table.
TCPIPPFX is defined in the DATASETPREFIX parameter in TCPDATA.
For CSSMTP there is a parameter named
Hello ,
I am working in israeli bank
And have a problem with
Hebrew characters
When i am sending email
By xmitip.
Hebrew characters doesn't
Translate.
Any suggestion how to solve
This problem ?
(Where and how to change the
Smtp translate characters table ?)
97 matches
Mail list logo