Lucas,
I think this is a mis-interpretation of your observations:
With /*JOBPARM SYSAFF: the job has affinity to the mentioned system: for
convertor, interpretor and execution, so here you can be sure of the
substituted values.
Without /*JOBPARM SYSAFF: the job can be handled by any system in
Thanks Kees, that's exactly what I tried to say and failed miserably :)
---
*Lucas Rosalen*
rosalen.lu...@gmail.com / lucas.rosal...@ibm.com
Lucas,
Ok, without SYSAFF, the submitting system has a good chance to handle the job
first, but I thought you meant to say that this was a rule.
We have seen the opposite, maybe because of JESs loads, that another system
than the submitting system handled most of the converts.
Kees.
>
On 21/06/2018 12:28 PM, Paul Gilmartin wrote:
I believe that symbols assigned values in a PROC statement or in EXEC PRC=
are local to that PROC (and its children?) Symbols assigned values in a SET
statement within a PROC are global. Ugh! It may be better to eschew SET
within a PROC; rather
Lionel, have you tried to locate the physical or electronic z/OS 2.2 media
you (or somebody else) ordered and used to upgrade your other system to
z/OS 2.2? That media should still work, and obviously somebody had
possession of that media at some point. Otherwise you wouldn't have a
system running
On Thu, 21 Jun 2018 09:34:48 +, Rob Scott wrote:
>>> On occasion I have been sorely vexed when I hastily issued SUBMIT from the
>>> SJ panel and discovered my sysins truncated to 80 characters. SUBMIT from
>>> SJ should preserve the attributes of the original job on resubmit.
>
>I must
On Thu, 21 Jun 2018 12:18:31 +0200, ITschak Mugzach wrote:
>The issue is applicable for jcl & instream data. The submitted JCL may
>include variables which after substitution may occupy larger space. SJ does
>not substitute. It uses the post substitution version of the JCL.
Under what
>> On occasion I have been sorely vexed when I hastily issued SUBMIT from the
>> SJ panel and discovered my sysins truncated to 80 characters. SUBMIT from
>> SJ should preserve the attributes of the original job on resubmit.
I must admit to being slightly puzzled by this statement.
JCL is, by
OK, I see now.
JES is storing the post-conversion JCL in the spool dataset that SDSF accesses
with SJ.
I imagine that there are cross-system and MAS reasons for that rather than
presenting the original JCL as symbols can change with time, date or local
system environment.
The system you "SJ"
Hi Doug,
Yeas the spool volume is in Draining Mode. I added a new spool volume.
How can i change de old volume? In draining mode?
Q ALLOC MAP
EXTENT EXTENT % ALLOCATION
VOLID RDEV STARTEND TOTAL IN USE HIGH USED TYPE
--
Here is a quick example of how SDSF can be used to provide the "Resubmit"
action on panels like "H", "ST" or "O".
To keep things brief, I have omitted environmental and error checking -
examples of which can be found in the SDSF manuals.
/* REXX */
/* Example
The issue is applicable for jcl & instream data. The submitted JCL may
include variables which after substitution may occupy larger space. SJ does
not substitute. It uses the post substitution version of the JCL.
ITschak
On Thu, Jun 21, 2018 at 11:34 AM, Rob Scott
wrote:
> >> On occasion I
On 6/20/2018 1:40 PM, Elardus Engelbrecht wrote:
Perhaps IBM should post somewhere for z/OS and other products the GA date, EOM date, EOS
date and also "end of download/order" date?
Check out the section "Product life cycle dates" (mind the wrap):
Hi Doug,
Because i tried the drain command and it's made no effect.
*drain dasd spool*
10:30:26 Command complete
Ready; T=0.01/0.01 10:30:26
*query alloc *
DASD 3332 M01RES
I've gotten good results with the EXPORT before the PROC, this example is
cut down from a working job:
//TSRCMHL1 JOB 1000,STEVE.SMITH,NOTIFY=,
// CLASS=C,MSGCLASS=X,COND=(1,LT)
// EXPORT SYMLIST=(PFX,VER,REL,FIX)
//HLDLIBS PROC PFX=RCM,VER=VV,REL=RR,FIX=TAC9
//AMS1EXEC
On Thu, 21 Jun 2018 14:28:51 +, Rob Scott wrote:
>From the start of the JCL user guide, there is a blanket statement of "A JCL
>statement consists of one or more 80-byte records".
>
That's not exactly true. IIRC, I've submitted JCL statements in records longer
than
80 bytes; columns 73
Except she was polite about it!
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent: Thursday, June 21, 2018 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done
Indeed! and articulated the z communities outage in a most civil manner
thank you Cheryl
Carmen Vitullo
- Original Message -
From: "Charles Mills"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, June 21, 2018 11:28:45 AM
Subject: Re: Would SHARE kindly kick IBM in the ass for what
I recently noticed we're receiving the following (maybe three times) on
the MVS log during HSM startup:
ARC0104I INVALID INITIALIZATION COMMAND
How can we tell which commands are generating this? I can find no
HSM-produced log of commands and responses. All I see are the responses.
Thanks,
Here's our take on this issue -
http://watsonwalker.com/what-is-happening-with-ibms-websites/
All my best,
Cheryl
===
Cheryl Watson
Watson & Walker, Inc.
www.watsonwalker.com
===
> JCL is, by definition, a sequence of 80-byte card images and any instream
> SYSIN
> will be taken as a sequence of 80-byte characters.
That may have been true in 1964; it has not been true for a very long time.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
As would be expected, Cheryl absolutely nailed it!
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cheryl Watson
Sent: Thursday, June 21, 2018 7:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would SHARE kindly kick IBM in
I was shocked when this article showed up on my front page on Reddit.
Perfectly stated!
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cheryl Watson
Sent: Thursday, June 21, 2018 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re:
From what I can tell from the documentation, both native TSO SUBMIT and ISPF
SUBMIT (via ISPCTLx) do not allow job submission for anything other than
RECFM=FB LRECL=80 datasets.
As SDSF "SJ" uses EDIF and implicitly ISPF SUBMIT it is limited by the TSO/ISPF
restrictions.
-Original
She generally is nice.
BTW, for those who don't know who she is, I strongly recommend that you take a
look at her newsletters.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Allan Staller
From the start of the JCL user guide, there is a blanket statement of "A JCL
statement consists of one or more 80-byte records".
However, looking at the SYSIN keyword it indeed says that the 80-byte limit is
a minimum length.
Looks like am never too old to learn something new...
-Original
Patient: Doctor, it hurts when I do SUBMIT!
Doctor: Nu, so don't do SUBMIT.
Maybe one of these days IBM will fix SUBMIT, but in the meantime just copy the
job to the Internal Reader.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM
Back when I had this issue, my only choice was to count responses and then
count commands. Some of the commands had relatively unique responses which
assisted in synching my counts. Based on your question, it appears that newer
versions of HSM don't provide any additional information.
If you
Please consider supporting these RFE's that I just submitted:
ISPF Point and Shoot Protected Fields
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=121576
And
Improve ISPF 3.17 by allowing CD on the command line
On 6/21/2018 12:14 PM, John McKown wrote:
How about just issuing each HSM command in the member as an operator
command, perhaps via (E)JES?
That's a thought, but what a *major* PITA. Most of our commands are
split across multiple lines with /* xxx */ comments interspersed. It
will be very
I believe JCL's set of "allowable" characters is only a fraction of any
code page. And probably only common code points.
sas
On Thu, Jun 21, 2018 at 3:12 PM, John McKown
wrote:
> On Thu, Jun 21, 2018 at 1:57 PM Steve Smith wrote:
>
> > "... a sequence of 80-byte characters. ". Is that
I have both LOG and PDA files. Never needed them, but the recomenadtion was to
have them active for IBM if needed.
DFHSM.LOGX
DFHSM.LOGY
DFHSM.PDOX
DFHSM.PDOY
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent:
Hi Mike,
I'm unable to replicate your problem. Please contact me directly and we
can try to get to the bottom of it. Thanks!
-Sue Shumway
On 06/21/18 3:47 PM, Mike Hochee wrote:
Yes, extremely well stated, and timely too!.
Ironically, it looks like the z/OS 2.2 Elements and Features
okay, I thought so, I was hoping it would provide more info
Carmen Vitullo
- Original Message -
From: "Ed Jaffe"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, June 21, 2018 1:22:08 PM
Subject: Re: ARC0104I INVALID INITIALIZATION COMMAND
On 6/21/2018 11:15 AM, Carmen Vitullo
On 6/21/2018 11:35 AM, Gibney, Dave wrote:
What is your SETSYS ACTLOGMSGLVL?
That parameter is not relevant here. I did have ACTLOGMSGLVL(REDUCED)
so, just to prove the point, I changed it to ACTLOGMSGLVL(FULL) and
recycled HSM. No difference...
--
Phoenix Software International
Edward E.
Just FYI...
https://www.bbc.com/news/science-environment-44554891
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent: Thursday, June 21, 2018 1:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ARC0104I INVALID INITIALIZATION COMMAND
>
> On 6/21/2018 11:59 AM, Gibney, Dave
I'd say that this is such an egregious oversight that it should be APARable
even after all this time. There's no statute of limitations on bad design.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
Isn't #1 impossible? From what I've retained (or think I have) of 3270
programming, a "tab" is merely the start of an unprotected field. Catch-22.
sas
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
I expected as much. Another possibility is to insert some LOG commands into
your ARCCMD00 perhaps even as frequently as to echo each SETSYS
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent: Thursday, June 21, 2018
On Thu, Jun 21, 2018 at 1:57 PM Steve Smith wrote:
> "... a sequence of 80-byte characters. ". Is that UTF-640 for true
> Universe-al support?
>
>
If I were a betting man, I'd give 1000:1 odds that JCL must be written in
CP-037 only, any non-CP027 characters would need to be in ' marks, like a
SHARE may not have kicked any @ss, but Cheryl got noticed.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Mark Regan
Sent: Thursday, June 21, 2018 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fwd: IBM shuffles mainframe
1,000 instructions per second times 20 to 30 million times faster is
20 to 30 GHz for a modern laptop? They got an extra zero in there.
On Thu, Jun 21, 2018 at 3:26 PM Mark Regan wrote:
>
> Just FYI...
>
> https://www.bbc.com/news/science-environment-44554891
>
>
We recently got a corrupted PO data set after using the PDS command to add
directory blocks. During the FIXPDS operation we were prompted to move members
to make room for additional directory blocks. SOP. We have done this so often
for such a long time that we didn't hesitate. Afterwards,
Steve Smith wrote:
>Isn't #1 impossible? From what I've retained (or think I have) of 3270
>programming, a "tab" is merely the start of an unprotected field.
Catch-22.
Correct. You cannot tab to a protected field. And I suspect that a request
for an update to the 3270 protocol is not likely
/* REXX */
'PIPE SAFE * | STEM MSG.'
TODataset = Word( Msg.3,3 )
mvs "send 'My console name is "TODataset"',CN=CNDVMSTR"
exit
Problem has been resolved by using sync command with option both.
Now, i used CN operand with send command to send message to operator
console and now i
"... a sequence of 80-byte characters. ". Is that UTF-640 for true
Universe-al support?
sas
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO
Yes, extremely well stated, and timely too!.
Ironically, it looks like the z/OS 2.2 Elements and Features pdf link
https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosv2r2-pdf-download?OpenDocument
now points at numerous z/OS 2.1 manuals. I don't know how extensive the
Bernd Oppolzer wrote:
At a site where I was working some years ago we had a site specific
debugging tool which inserted break points into test objects (= load
modules) by changing certain instruction's opcodes to hex zero, then
catching the resulting 0C1 interrupts and this way tracking the
On 6/21/2018 11:59 AM, Gibney, Dave wrote:
I expected as much. Another possibility is to insert some LOG commands into
your ARCCMD00 perhaps even as frequently as to echo each SETSYS
I thought we could try something like that, but it seems that some (or
maybe all?) of the commands are being
Been a while for me supporting / having HSM
IIRC isn't there a LOG1 + LOG2 that goes to a dataset?
Carmen Vitullo
- Original Message -
From: "Ed Jaffe"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, June 21, 2018 1:00:51 PM
Subject: ARC0104I INVALID INITIALIZATION COMMAND
I
On 6/21/2018 11:15 AM, Carmen Vitullo wrote:
Been a while for me supporting / having HSM
IIRC isn't there a LOG1 + LOG2 that goes to a dataset?
Yes. Such data sets exist. Browsing under ISPF you see only the comman
responses, not the commands themselves. For example, I see "SETSYS
COMMAND
Good article, of course, Cheryl.
The one thing it didn't mention is that maintenance of these sites is being
moved overseas. That's not inherently bad, except that it inevitably leads
to a loss of tribal knowledge, which may be how these huge omissions
occurred.
On Thu, Jun 21, 2018 at 1:06 PM,
https://www.theregister.co.uk/2018/06/21/ibm_mainframe_docs/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
On 6/21/2018 2:17 PM, Gibney, Dave wrote:
Looking some more and remembering. Do you have the HSM PDA (Problem
Determination AID) active? SETSYS PDS() and a couple datasets.
I have a vague memory that this data can also be found using IPCS against the
active region. Or something.
Yes. I
What is your SETSYS ACTLOGMSGLVL?
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent: Thursday, June 21, 2018 11:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ARC0104I INVALID INITIALIZATION COMMAND
>
> I recently
On Thu, Jun 21, 2018 at 1:53 PM Ed Jaffe
wrote:
> On 6/21/2018 11:35 AM, Gibney, Dave wrote:
> > What is your SETSYS ACTLOGMSGLVL?
>
> That parameter is not relevant here. I did have ACTLOGMSGLVL(REDUCED)
> so, just to prove the point, I changed it to ACTLOGMSGLVL(FULL) and
> recycled HSM. No
Hi Sue,
It is working again now, and I'm noticing an updated look and feel with the
2.2 Elements and Features page. In my previous attempts, I opened new z.OS 2.2
Elements and Features tabs. This time however, I shutdown all tabs and
restarted the browser. Regardless, it's working - Thank
Looking some more and remembering. Do you have the HSM PDA (Problem
Determination AID) active? SETSYS PDS() and a couple datasets.
I have a vague memory that this data can also be found using IPCS against the
active region. Or something.
> -Original Message-
> From: IBM Mainframe
On 6/21/2018 11:00 AM, Ed Jaffe wrote:
I recently noticed we're receiving the following (maybe three times)
on the MVS log during HSM startup:
ARC0104I INVALID INITIALIZATION COMMAND
Found them! How? Via manual inspection! (HSM facilities were no help AT
ALL...)
I used ISPF highlighting
On Thu, 21 Jun 2018 19:08:53 +, Dyck, Lionel B. (RavenTek) wrote:
>Please consider supporting these RFE's that I just submitted:
>
>ISPF Point and Shoot Protected Fields
>
>https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=121576
On Thu, 21 Jun 2018 18:13:21 -0400, Phil
On Thu, 21 Jun 2018 21:21:56 -0400, Steve Smith wrote:
>My only point was the SET wasn't needed the way I used symbols. It's
>hardly any big deal if it's needed for library PROCs. The fact that
>there doesn't seem to be any obvious logical reason for it, is just one
>of things you take for
On 22/06/2018 11:21 AM, Steve Smith wrote:
Why don't we just skip the JCL, and write our jobs in REXX? The two
main things JCL does, EXEC and DD, are just as easy in REXX, (call,
alloc) with a ton more flexibility. EXPORT, SET, IF, and symbols are
lipstick for a pig.
I actually like JCL.
Gil wrote:
>Does 3270 protocol require that PAS fields be writable, therefore tabbable?
>Bad design. It's perfectly reasonable to want to specify a read-only PAS
>menu item. (Too few bits in the attribute byte?)
I've done lots of 3270 programming, but am unaware of what a point-and-shoot
On 6/21/2018 6:47 PM, Phil Smith III wrote:
Gil wrote:
Does 3270 protocol require that PAS fields be writable, therefore tabbable?
Bad design. It's perfectly reasonable to want to specify a read-only PAS
menu item. (Too few bits in the attribute byte?)
I've done lots of 3270 programming,
On Thu, 21 Jun 2018 19:23:28 -0700, Ed Jaffe wrote:
>On 6/21/2018 6:47 PM, Phil Smith III wrote:
>
>That's funny! Of course, there is no such things as a "point and shoot"
>field in 3270! LOL!
>
>The notion of "point and shoot" hinges entirely on how the 3270
>application in question chooses to
On 21/06/2018 11:05 PM, Steve Smith wrote:
I've gotten good results with the EXPORT before the PROC
Which means the EXPORT needs to be in the calling job, not the PROC. My
examples used inline PROCs for convenience, but I was trying to do it
with a PROC in a PROCLIB. If the EXPORT needs to
On Fri, 22 Jun 2018 10:34:54 +1000, Andrew Rowley
wrote:
>On 21/06/2018 11:05 PM, Steve Smith wrote:
>> I've gotten good results with the EXPORT before the PROC
>
>Which means the EXPORT needs to be in the calling job, not the PROC. My
>examples used inline PROCs for convenience, but I was
On Thu, 21 Jun 2018 19:08:53 +, Dyck, Lionel B. (RavenTek) wrote:
>Please consider supporting these RFE's that I just submitted:
>
>ISPF Point and Shoot Protected Fields
>
>https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=121576
>
No need to change the sematics of . Use
My only point was the SET wasn't needed the way I used symbols. It's
hardly any big deal if it's needed for library PROCs. The fact that
there doesn't seem to be any obvious logical reason for it, is just one
of things you take for granted with JCL.
Why don't we just skip the JCL, and
Hello Group,
/* REXX */
'PIPE SAFE * | STEM MSG.'
TODataset = Word( Msg.3,3 )
mvs "send 'My console name is "TODataset"',CN=CNDVMSTR"
exit
We used CN operand with send command to send message to operator console
and now i receive output as required.
But this message is visible
Gadi Ben-Avi asked:
>Will it give better performance than Hypersockets?
Yes, for anything that can exploit SMC-D (which is anything sockets-based,
z/OS to z/OS).(*) If you go look at the presentation provided in the first
link on the Web page I referenced, on page 11, there's this statement from
Andrew Rowley wrote:
>> to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place it in
>> a JCL comment):
>> //* DELETE KVPO.MOST.DB2DATA.
>> //SYSIN DD *,SYMBOLS=(JCLONLY,X)
>> SET MAXCC = 0
>Unfortunately that may not work because the symbols in SYSIN are not
>substituted the
On the side topic...
Based on our latest "experience":
- without /*JOBPARM SYSAFF: symbols got resolved in the submitting LPAR,
which caused some problems as they were different from the executing LPAR
(and used as a dataset qualifier);
- with /*JOBPARM SYSAFF: symbols are resolved in the
74 matches
Mail list logo
