AW: Re: Formatting
>My post did not come out as I expected. No flowing. I'm going to shut up. I concur. When I read the explanation regarding "leading or trailing" blanks, I thought I finally understand. Then came your post, and I'm back to "I don't have a clue why it sometimes does work, and sometimes it does not". -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Transaction jobs?
On 7/2/2018 5:45 PM, Charles Mills wrote: Thanks. Can I do it with a UNIX command without programming? Absolutely! If you write sysout from z/OS UNIX you are creating that kind of output. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Transaction jobs?
Thanks. Can I do it with a UNIX command without programming? (Not that I don't love to program ...) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, July 2, 2018 4:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Transaction jobs? On 7/2/2018 3:22 PM, Charles Mills wrote: > The SSI manual makes repeated references to "transaction job IDs" and > "transaction job names." > > What is a "transaction job" in this sense? APPC/MVS and z/OS UNIX transactions create output, but are never assigned complete JES job structures. For APPC/MVS the output is aggregated under ASCHINT address spaces and for z/OS UNIX under BPXAS. You can experiment and create "transaction jobs" yourself (in batch, under TSO, wherever) by creating your own subtask JSAB using the provided services. Here is me fooling around (under JES2) with various job names and a jobid called CRAZYBOY. LOL: Jobs JES System Tools Filter View Options Help -- STATUS 2,190S 1X 31W 0H 0T 186,581 Records 0 Pages Command ===> Cmd JobName JobIDStatus QueueAMbr JP Pos WPos MaxComp Records --- /-- -- --- -- EDJAFFE T0021179 QUEUED PRINT 1 891 AB S622 392 EDJAFFE T0200608 QUEUED PRINT 1 243 CC 37 YOURENOT CRAZYBOY QUEUED PRINT 1 243 87 SMFDUMP CRAZYBOY QUEUED PRINT 1 243 87 -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO TEST breakpoint subcommand call either looping or not being executed
Didn’t know you can put in parens to force sequence of execution > On Jul 2, 2018, at 4:31 PM, Binyamin Dissen > wrote: > > If I understand you correctly and you repetitively want this to occur, you > will need: > > AT +8 (AT +C (off +c;call ..;go);go) > > (assuming you want the CALL after the STM) > > > On Mon, 2 Jul 2018 16:07:38 -0400 Joseph Reichman > wrote: > > :>Binyamin > :> > :>For example AT +8 (CALL PROGRAM PARM(parms) RETRUN(+C)) > :>If +8 contains a STM r0,r15,saveregs in this scenario the STM is never > :>executed and return to +C > :> > :>If for example at +8 (call program PARAM(parms) Return(+8)) the program is > :>called repeatedly > :> > :>I would like what is +8 to get executed after the call or execute +8 the STM > :>and then called program then go to the NSI > :> > :>Cann't figure out the syntax to make this work > :> > :>Thanks > :> > :>-Original Message- > :>From: IBM Mainframe Discussion List On Behalf Of > :>Binyamin Dissen > :>Sent: Monday, July 2, 2018 3:59 PM > :>To: IBM-MAIN@LISTSERV.UA.EDU > :>Subject: Re: TSO TEST breakpoint subcommand call either looping or not being > :>executed > :> > :>On Mon, 2 Jul 2018 15:37:34 -0400 Joseph Reichman > :>wrote: > :> > :>:>I have a TSO TEST breakpoint with a call subcommand when I return to the > :>:>offset of the breakpoint the program loops over and over again. When I > :>:>return to the NSI the instruction where the breakpoint is doesn't get > :>:>executed > :> > :>I do not understand your scenario. > :> > :>You are setting a breakpoint and at the breakpoint you issue the CALL > :>subcommand? > :> > :>What OPCODE are you breakpointing on? > :> > :>What is the exact CALL command used? > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Transaction jobs?
On 7/2/2018 3:22 PM, Charles Mills wrote: The SSI manual makes repeated references to "transaction job IDs" and "transaction job names." What is a "transaction job" in this sense? APPC/MVS and z/OS UNIX transactions create output, but are never assigned complete JES job structures. For APPC/MVS the output is aggregated under ASCHINT address spaces and for z/OS UNIX under BPXAS. You can experiment and create "transaction jobs" yourself (in batch, under TSO, wherever) by creating your own subtask JSAB using the provided services. Here is me fooling around (under JES2) with various job names and a jobid called CRAZYBOY. LOL: Jobs JES System Tools Filter View Options Help -- STATUS 2,190S 1X 31W 0H 0T 186,581 Records 0 Pages Command ===> Cmd JobName JobID Status Queue AMbr JP Pos WPos MaxComp Records --- /-- -- --- -- EDJAFFE T0021179 QUEUED PRINT 1 891 AB S622 392 EDJAFFE T0200608 QUEUED PRINT 1 243 CC 37 YOURENOT CRAZYBOY QUEUED PRINT 1 243 87 SMFDUMP CRAZYBOY QUEUED PRINT 1 243 87 -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSE splits from Microfocus
A good deal for MicroFocus. They bought the whole dang thing of Attachmate for $1.2B. They just sold one part of that for $2.5B. Wish I was that smart. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Schramm Sent: Monday, July 2, 2018 4:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SUSE splits from Microfocus https://itsfoss.com/suse-eqt-acquisition/ Can anyone spell "we need cash"? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SUSE splits from Microfocus
https://itsfoss.com/suse-eqt-acquisition/ Can anyone spell "we need cash"? Rob Schramm -- Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting
My post did not come out as I expected. No flowing. I'm going to shut up.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Seymour J Metz
Sent: Monday, July 02, 2018 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Formatting
> This code looks fine. My experience in posting to IBM-MAIN is that
>spaces at the beginning *or end*
> of a line allows the data to look fine. But truncating both leading
>and trailing spaces causes the List processor to flow lines up to the
>next 'break',
That sounds seriously b0rken. Can that behavior be turned off, or is it hard
wired.
BTW, your line 1 -3 appear fine.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Jesse 1 Robinson
Sent: Sunday, July 1, 2018 7:37 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Formatting
This code looks fine. My experience in posting to IBM-MAIN is that spaces at
the beginning *or end* of a line allows the data to look fine. But truncating
both leading and trailing spaces causes the List processor to flow lines up to
the next 'break', which may be a totally blank line. I try to copy lines from,
say, syslog, to include trailing blanks. If there are none on a particular
line, I hit the space bar after the last character.
Sending notes internally with the company does not involve these issues.
These lines have no leading or trailing blanks.
line 1 typed in
line 2 typed in
line 3 typed in
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Ed Jaffe
Sent: Sunday, July 01, 2018 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Formatting
On 7/1/2018 11:39 AM, Seymour J Metz wrote:
>> I consider RFC 3676 an abomination, totally unsuitable for posting
>> code samples.
> Why? Do you know of any case where a properly behaving mail client mangles
> code properly formatted with format=flowed?
AFAIK, I've never had an issue posting code fragments on any list. I'm gonna
experiment with one right now randomly taken from our local REXX library. What
am I doing wrong? (Or right?)
/* REXX */
TSMRMM:
address tso
/* trace I */
"bpxbatch sh dsmadmc -id=mvs60 -pa=xx -displ=tab",
/* "q volhist begindate=TODAY-1 begintime=15:00:00" */ ,
/* "enddate=TODAY-1 endtime=23:00:00" */ ,
"q volhist begindate=today" ,
"> /tmp/tsmrmm.qvolhist"
if rc <> 0 then exit 8
"allocate dd(tsmrpt) path('/tmp/tsmrmm.qvolhist')",
"recfm(v) lrecl(1024) filedata(text) reuse"
if rc <> 0 then exit 8
volcount = 0
"execio * diskr tsmrpt (stem rptline. open finis"
do i=1 to rptline.0
do j = 1 to words(rptline.i)
if LEFT(WORD(rptline.i,j),6) = "BACKUP" |,
LEFT(WORD(rptline.i,j),3) = "STG" then,
do
do k=j to words(rptline.i)
if LEFT(WORD(rptline.i,k),4) = "3590" then,
do
volcount = volcount + 1
type.volcount = WORD(rptline.i,j)
dev.volcount = WORD(rptline.i,k)
vol.volcount = WORD(rptline.i,k+1)
leave k
end
end
leave j
end
end
end
do i=1 to volcount
say "VolHist:" type.i dev.i vol.i
select
when type.i = "STGNEW" |,
LEFT(type.i,6) = "BACKUP" then,
do
rmmcmd = "RMM CV" vol.i "STATUS(MASTER) HOLD",
"OWNER(TIVSM) RELEASEACTION(ERASE)"
address tso rmmcmd
cc = rc
say "Command:" rmmcmd
say "RetCode:" cc
rmmcmd = "RMM CV" vol.i "LOCATION(SHELF)"
if dev.i ="3590VAULT1" then,
rmmcmd = "RMM CV" vol.i "MANUALMOVE LOCATION(FRED)"
address tso rmmcmd
cc = rc
say "Command:" rmmcmd
say "RetCode:" cc
end
when type.i = "STGDELETE" then,
do
rmmcmd = "RMM CV" vol.i "AUTOMOVE NOHOLD"
address tso rmmcmd
cc = rc
say "Command:" rmmcmd
say "RetCode:" cc
rmmcmd = "RMM DV" vol.i "RELEASE"
.
. (etc)
.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting (was: JCL ERROR : IGD01022I)
Sort of an amalgamation from long ago posts. Just trying to dodge the lightning bolts. Guess it could mean senior techy too. In a message dated 7/2/2018 5:06:42 PM Central Standard Time, edja...@phoenixsoftware.com writes: Was this intended to be "Señor Jaffe?" Or was it a comment on my age and/or experience? ;-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting (was: JCL ERROR : IGD01022I)
There you go using them dang Unicode characters again. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, July 2, 2018 3:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Formatting (was: JCL ERROR : IGD01022I) On 7/2/2018 11:55 AM, Edward Finnell wrote: > I looked at the archives and Senior Jaffe's post appears correctly formatted. > It has plain/text and proportional font. Was this intended to be "Señor Jaffe?" Or was it a comment on my age and/or experience? ;-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Transaction jobs?
The SSI manual makes repeated references to "transaction job IDs" and "transaction job names." What is a "transaction job" in this sense? Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting (was: JCL ERROR : IGD01022I)
On 7/2/2018 11:55 AM, Edward Finnell wrote: I looked at the archives and Senior Jaffe's post appears correctly formatted. It has plain/text and proportional font. Was this intended to be "Señor Jaffe?" Or was it a comment on my age and/or experience? ;-) -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Mon, 2 Jul 2018 14:41:44 -0400, Steve Smith wrote: >There appears to be a visceral urge in some to force others to conform to >their great vision of the new and better way (ergo DST). That isn't at all >necessary ... Just do it. Yourself. > Force? Not in that case. Set your wrist watch to whatever offset you choose. Publish the hours of operation of your business in whatever timezone, Standard, Daylight, UTC, whatever. But things work better if people agree. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
D'accord - and the next 'complaint' will be about that pesky machine code and how to get rid of it. Those who find JCL challenging argue that it is not needed. As Aesop's fox said, "the grape is sour." My ha'penny. CP On 02/07/2018 19:41, Steve Smith wrote: > There appears to be a visceral urge in some to force others to conform to > their great vision of the new and better way (ergo DST). That isn't at all > necessary in this case (nor DST). Just do it. Yourself. Now, or whenever > you have the time. > > The simultaneous enqueue issue seems to be the biggest technical issue. I > see these possible solutions: > a) Use JCL... > b) Write a utility that will do it. > c) Avoid the need for it. > > JCL is not ever going away, and to interact with the system as it exists, > some JCL is going to be needed. A JOB card, an EXEC PGM=IRXJCL (a somewhat > ironic name), and //SYSEXEC DD. But that would be a generic template, > depending on what you need to do with JOB card parameters. > > Start small... you don't have to build Rome in one day, or boil the ocean. > > sas > > On Mon, Jul 2, 2018 at 2:26 PM, Paul Gilmartin < > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote: >> >>> Oh my gosh, you would have to maintain JCL forever for that and a dozen >> other reasons. >>> BUT! Conceivably ... conceivably ... you might stabilize it and do >> everything new in Rexx going forward. >> If the replacement had a superset of JCL function, providing a >> JCL-to-replacement >> translation utility would allow discarding direct support for JCL. >> >>> -Original Message- >>> From: John Melcher, Jr >>> Sent: Monday, July 2, 2018 10:46 AM >>> >>> Once upon a time a LONG time ago this was a GUIDE requirement. It was >>> voted down due to the amount of automated systems that generated JCL. >>> You'd have to keep JCL, probably forever, because of those systems. >> -- gil >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Question about the z/OS Binder API
The documentation for the z/OS V2.2 Binder API in the manual "z/OS MVS Program Management: Advanced Facilities" in "Appendix D. Binder API buffer formats", page 279 (PDF page count 297) has a footnote #3 for field ESD_ELEM_OFFSET which says: 3. Calculated on the ED and ER records, required input to LD. That note says to me that if I INCLUDE an existing program (object or load module) into a Binder work space using the Binder API's, then for ED entries in the ESD obtained for that program using FUNC=GETD for TYPE=ESD I should see the element offset for the class of that section. As it turns out, the Binder API FUNC=GETD for TYPE=ESD always returns a binary zero in that field. No matter what VERSION level of the API macros is used (I have tried all version numbers from 4 up to 7) the field ESD_ELEM_OFFSET is always a zero. This holds true for both program objects loaded form a PDSE and load modules loaded from a PDS. For load modules loaded from a PDS, the "class" offset is actually zero (B_TEXT is the only class of a load module) so the zero value for a load module loaded form a PDS is actually accurate. However, for a complex program object (COBOL V5+ or C/C++, etc.) it is not accurate. The other offset field in the ED entry (field ESD_CLASS_OFFSET) accurately contains the offset from the start of the containing Binder class section, but nowhere does the ED entry contain the offset of the CLASS from the start of the loaded program. It was my impression (perhaps wrongly) that the Binder API should tell me that offset in each ED entry for an ESD section. To get to the actual start of a particular section of code in a loaded program it seems that you also have to use FUNC=GETN for NTYPE=CLASS to get all of the CLASS names and their respective offsets (field name BNL_SEGM_OFF) and add that value to the ESD_CLASS_OFFSET to find the code in storage. Which means you have to search the CLASS names table for each ED section name using the name at ESD_RES_CLASS_PTR to find the containing class name and then extract the offset from that CLASS entry. Is this expected behavior of the Binder API, or is this a possible error/failure in the API? Should that class offset value from BNL_SEGM_OFF in the CLASS entry also be stored into the ESD_ELEM_OFFSET field automatically by the Binder API when a module is INCLUDEd into a workspace, or not? If I am just misreading the API documentation, I would appreciate any enlightenment you can provide. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?
On Mon, 2 Jul 2018 15:53:02 -0400, Joe Monk wrote: >I think it is saying that the system picks the volume from the referenced >dsn, which must be cataloged (i.e. can't be a temp data set). >On Mon, Jul 2, 2018 at 3:49 PM, Paul Gilmartin wrote: >> > >> > https://www.ibm.com/support/knowledgecenter/en/CD_PROC_LANG/com.ibm.help.cdprocstmtsparams.doc/cdproc_stmt_zos_Process_Parameters.html >> > >> ... If VOL is not specified with the FROM parameter, the file must be >> cataloged. >> This appears to be "the exception that proves the rule": https://en.wikipedia.org/wiki/Exception_that_proves_the_rule#Original_meaning According to Cicero, this means that if VOL *is* specified on the FROM parameter, the "file" need not be catalogued. Must FROM and TO refer to the same dsn? If so, wouldn't it be copying a data set over itself? Or might "file" be a different member of the same PDS(E)? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO TEST breakpoint subcommand call either looping or not being executed
Either way as long as the breakpoint instruction Gets executed I’ll try it when I get home thanks Joe Reichman 170-10 73 rd ave Fresh meadows NY 11366 > On Jul 2, 2018, at 4:31 PM, Binyamin Dissen > wrote: > > If I understand you correctly and you repetitively want this to occur, you > will need: > > AT +8 (AT +C (off +c;call ..;go);go) > > (assuming you want the CALL after the STM) > > > On Mon, 2 Jul 2018 16:07:38 -0400 Joseph Reichman > wrote: > > :>Binyamin > :> > :>For example AT +8 (CALL PROGRAM PARM(parms) RETRUN(+C)) > :>If +8 contains a STM r0,r15,saveregs in this scenario the STM is never > :>executed and return to +C > :> > :>If for example at +8 (call program PARAM(parms) Return(+8)) the program is > :>called repeatedly > :> > :>I would like what is +8 to get executed after the call or execute +8 the STM > :>and then called program then go to the NSI > :> > :>Cann't figure out the syntax to make this work > :> > :>Thanks > :> > :>-Original Message- > :>From: IBM Mainframe Discussion List On Behalf Of > :>Binyamin Dissen > :>Sent: Monday, July 2, 2018 3:59 PM > :>To: IBM-MAIN@LISTSERV.UA.EDU > :>Subject: Re: TSO TEST breakpoint subcommand call either looping or not being > :>executed > :> > :>On Mon, 2 Jul 2018 15:37:34 -0400 Joseph Reichman > :>wrote: > :> > :>:>I have a TSO TEST breakpoint with a call subcommand when I return to the > :>:>offset of the breakpoint the program loops over and over again. When I > :>:>return to the NSI the instruction where the breakpoint is doesn't get > :>:>executed > :> > :>I do not understand your scenario. > :> > :>You are setting a breakpoint and at the breakpoint you issue the CALL > :>subcommand? > :> > :>What OPCODE are you breakpointing on? > :> > :>What is the exact CALL command used? > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO TEST breakpoint subcommand call either looping or not being executed
If I understand you correctly and you repetitively want this to occur, you will need: AT +8 (AT +C (off +c;call ..;go);go) (assuming you want the CALL after the STM) On Mon, 2 Jul 2018 16:07:38 -0400 Joseph Reichman wrote: :>Binyamin :> :>For example AT +8 (CALL PROGRAM PARM(parms) RETRUN(+C)) :>If +8 contains a STM r0,r15,saveregs in this scenario the STM is never :>executed and return to +C :> :>If for example at +8 (call program PARAM(parms) Return(+8)) the program is :>called repeatedly :> :>I would like what is +8 to get executed after the call or execute +8 the STM :>and then called program then go to the NSI :> :>Cann't figure out the syntax to make this work :> :>Thanks :> :>-Original Message- :>From: IBM Mainframe Discussion List On Behalf Of :>Binyamin Dissen :>Sent: Monday, July 2, 2018 3:59 PM :>To: IBM-MAIN@LISTSERV.UA.EDU :>Subject: Re: TSO TEST breakpoint subcommand call either looping or not being :>executed :> :>On Mon, 2 Jul 2018 15:37:34 -0400 Joseph Reichman :>wrote: :> :>:>I have a TSO TEST breakpoint with a call subcommand when I return to the :>:>offset of the breakpoint the program loops over and over again. When I :>:>return to the NSI the instruction where the breakpoint is doesn't get :>:>executed :> :>I do not understand your scenario. :> :>You are setting a breakpoint and at the breakpoint you issue the CALL :>subcommand? :> :>What OPCODE are you breakpointing on? :> :>What is the exact CALL command used? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO TEST breakpoint subcommand call either looping or not being executed
Binyamin For example AT +8 (CALL PROGRAM PARM(parms) RETRUN(+C)) If +8 contains a STM r0,r15,saveregs in this scenario the STM is never executed and return to +C If for example at +8 (call program PARAM(parms) Return(+8)) the program is called repeatedly I would like what is +8 to get executed after the call or execute +8 the STM and then called program then go to the NSI Cann't figure out the syntax to make this work Thanks -Original Message- From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen Sent: Monday, July 2, 2018 3:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO TEST breakpoint subcommand call either looping or not being executed On Mon, 2 Jul 2018 15:37:34 -0400 Joseph Reichman wrote: :>I have a TSO TEST breakpoint with a call subcommand when I return to the :>offset of the breakpoint the program loops over and over again. When I :>return to the NSI the instruction where the breakpoint is doesn't get :>executed I do not understand your scenario. You are setting a breakpoint and at the breakpoint you issue the CALL subcommand? What OPCODE are you breakpointing on? What is the exact CALL command used? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO TEST breakpoint subcommand call either looping or not being executed
On Mon, 2 Jul 2018 15:37:34 -0400 Joseph Reichman wrote: :>I have a TSO TEST breakpoint with a call subcommand when I return to the :>offset of the breakpoint the program loops over and over again. When I :>return to the NSI the instruction where the breakpoint is doesn't get :>executed I do not understand your scenario. You are setting a breakpoint and at the breakpoint you issue the CALL subcommand? What OPCODE are you breakpointing on? What is the exact CALL command used? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting (was: JCL ERROR : IGD01022I)
Definitely an admin question. The other interlocutor is the distribution server that takes the listserv post and spews it out to the subscribers. It may be munging for compression or just that's all it knows. In a message dated 7/2/2018 2:28:25 PM Central Standard Time, 000433f07816-dmarc-requ...@listserv.ua.edu writes: Later, I retrieved the same message with a GETPOST command to LISTSERV and in the same mail reader all the blanks were blanks. They can't both be right. At best, LISTSERV's behavior is inconsistent. But how can I generate an SR to L-Soft? I'm not the customer and Darren is inactive. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?
I think it is saying that the system picks the volume from the referenced dsn, which must be cataloged (i.e. can't be a temp data set). Joe On Mon, Jul 2, 2018 at 3:49 PM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 2 Jul 2018 15:07:07 -0400, Joe Monk wrote: > > >REF allows you to place a data set on the same volume as the referenced > >data set. It must be cataloged on the system where it is referenced. > > > >https://www.ibm.com/support/knowledgecenter/en/CD_PROC_LANG/com.ibm.help. > cdprocstmtsparams.doc/cdproc_stmt_zos_Process_Parameters.html > > > Not always, but good point: > ([SER=(serial-no, [serial-no,...]) | ,REF=dsn]) > specifies the volume serial number(s) containing the file and > optional processing associated > with the file. If VOL is not specified with the FROM parameter, > the file must be cataloged. > > (They're careless about distinction between "file" and "data set".) > > Is this trying to say that the default VOL for TO is the VOL specified on > FROM? > > Is it possible that Lionel is referring to a data set created in the same > COPY > command and COPY does not ALLOCATE/CATALOG that data set until the > command runs? > > But Lionel seems to indicate he's seeing a syntax error, not "Data set not > found". > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?
On Mon, 2 Jul 2018 15:07:07 -0400, Joe Monk wrote: >REF allows you to place a data set on the same volume as the referenced >data set. It must be cataloged on the system where it is referenced. > >https://www.ibm.com/support/knowledgecenter/en/CD_PROC_LANG/com.ibm.help.cdprocstmtsparams.doc/cdproc_stmt_zos_Process_Parameters.html > Not always, but good point: ([SER=(serial-no, [serial-no,...]) | ,REF=dsn]) specifies the volume serial number(s) containing the file and optional processing associated with the file. If VOL is not specified with the FROM parameter, the file must be cataloged. (They're careless about distinction between "file" and "data set".) Is this trying to say that the default VOL for TO is the VOL specified on FROM? Is it possible that Lionel is referring to a data set created in the same COPY command and COPY does not ALLOCATE/CATALOG that data set until the command runs? But Lionel seems to indicate he's seeing a syntax error, not "Data set not found". -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
TSO TEST breakpoint subcommand call either looping or not being executed
Hi I have a TSO TEST breakpoint with a call subcommand when I return to the offset of the breakpoint the program loops over and over again. When I return to the NSI the instruction where the breakpoint is doesn't get executed Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?
Folks: If it is documented (and I don't have time to pull down the latest doc), it will get addressed as a problem and not an RFE. The C:D change team and the dev guys know the internals of the product very well. Regards, Steve Thompson On 07/02/2018 02:26 PM, Dyck, Lionel B. (RavenTek) wrote: I don't think I can accept an RFE on this one - the documentation clearly shows it should work :-) That and we need it to work -- Lionel B. Dyck (Contractor) < Mainframe Systems Programmer – RavenTek Solution Partners -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, July 02, 2018 1:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ? On Mon, 2 Jul 2018 17:26:00 +, Dyck, Lionel B. (RavenTek) wrote: The use of VOL=SER=xx works but that is only useful for the 1st data set being copied. I've tried variations of ,'s also without success. Time for a PMR :-) What if they tell you that has to be an RFE? (I suppose that if there is a documented function that simply doesn't work, PMR should be accepted.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?
REF allows you to place a data set on the same volume as the referenced data set. It must be cataloged on the system where it is referenced. https://www.ibm.com/support/knowledgecenter/en/CD_PROC_LANG/com.ibm.help.cdprocstmtsparams.doc/cdproc_stmt_zos_Process_Parameters.html Joe On Mon, Jul 2, 2018 at 2:26 PM, Dyck, Lionel B. (RavenTek) < lionel.d...@va.gov> wrote: > I don't think I can accept an RFE on this one - the documentation clearly > shows it should work :-) > > That and we need it to work > > -- > Lionel B. Dyck (Contractor) < > Mainframe Systems Programmer – RavenTek Solution Partners > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Monday, July 02, 2018 1:22 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ? > > On Mon, 2 Jul 2018 17:26:00 +, Dyck, Lionel B. (RavenTek) wrote: > > >The use of VOL=SER=xx works but that is only useful for the 1st data > set being copied. I've tried variations of ,'s also without success. > > > >Time for a PMR :-) > > > What if they tell you that has to be an RFE? (I suppose that if there is a > documented function that simply doesn't work, PMR should be accepted.) > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting (was: JCL ERROR : IGD01022I)
I looked at the archives and Senior Jaffe's post appears correctly formatted. It has plain/text and proportional font.AFAIK, I've never had an issue posting code fragments on any list. I'm gonna experiment with one right now randomly taken from our local REXX library. What am I doing wrong? (Or right?) /* REXX */ TSMRMM: address tso /* trace I */ "bpxbatch sh dsmadmc -id=mvs60 -pa=xx -displ=tab", /* "q volhist begindate=TODAY-1 begintime=15:00:00" */ , /* "enddate=TODAY-1 endtime=23:00:00" */ , "q volhist begindate=today" , "> /tmp/tsmrmm.qvolhist" if rc <> 0 then exit 8 "allocate dd(tsmrpt) path('/tmp/tsmrmm.qvolhist')", "recfm(v) lrecl(1024) filedata(text) reuse" if rc <> 0 then exit 8 volcount = 0 In a message dated 7/2/2018 1:31:00 PM Central Standard Time, sme...@gmu.edu writes: AFAIK, I have never used KOI8-R; I can't speak to what m$ outhouse may have done behind my back. Maybe it copied the charset from the message I was responding to? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
There appears to be a visceral urge in some to force others to conform to their great vision of the new and better way (ergo DST). That isn't at all necessary in this case (nor DST). Just do it. Yourself. Now, or whenever you have the time. The simultaneous enqueue issue seems to be the biggest technical issue. I see these possible solutions: a) Use JCL... b) Write a utility that will do it. c) Avoid the need for it. JCL is not ever going away, and to interact with the system as it exists, some JCL is going to be needed. A JOB card, an EXEC PGM=IRXJCL (a somewhat ironic name), and //SYSEXEC DD. But that would be a generic template, depending on what you need to do with JOB card parameters. Start small... you don't have to build Rome in one day, or boil the ocean. sas On Mon, Jul 2, 2018 at 2:26 PM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote: > > >Oh my gosh, you would have to maintain JCL forever for that and a dozen > other reasons. > > > >BUT! Conceivably ... conceivably ... you might stabilize it and do > everything new in Rexx going forward. > > > If the replacement had a superset of JCL function, providing a > JCL-to-replacement > translation utility would allow discarding direct support for JCL. > > >-Original Message- > >From: John Melcher, Jr > >Sent: Monday, July 2, 2018 10:46 AM > > > >Once upon a time a LONG time ago this was a GUIDE requirement. It was > >voted down due to the amount of automated systems that generated JCL. > >You'd have to keep JCL, probably forever, because of those systems. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: REXX as JCL replacement
I like this up to a point - I would prefer to have an execution command and
then be able to do if/then/else and another step, etc.
Or just use standard TSO allocation and program call syntax, perhaps simplified
to be more JCL 'like'
--
Lionel B. Dyck (Contractor) <
Mainframe Systems Programmer – RavenTek Solution Partners
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Hobart Spitz
Sent: Monday, July 02, 2018 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: REXX as JCL replacement
How about something like this?
Use REXX syntax and a JCL host command with JCL-like semantics:
/* REXX */
arg String /* From SUBMIT or start task command. */
"jcl job myjob: (acct),'john smith',class=t,msgclass=h,notify="userid()
"jcl exec pgm=myprog,parm="date("s")
"jcl sysprint: dd sysout=*"
"jcl sysin dd *"
"jcl data" String
...
The JCL host command could create the exact same control blocks as the
existing JCL statements today, but not begin execution. When the REXX exec
exited, ENQs would be processed as now, followed by the current processing,
including step execution, and cleanup. All exit/interfaces would be
preserved so that third-party software would still work unchanged.
OREXXMan
JCL is the buggy whip of 21st century computing. Stabilize it.
Put Pipelines in the z/OS base. Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.
On Mon, Jul 2, 2018 at 2:26 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote:
>
> >Oh my gosh, you would have to maintain JCL forever for that and a dozen
> other reasons.
> >
> >BUT! Conceivably ... conceivably ... you might stabilize it and do
> everything new in Rexx going forward.
> >
> If the replacement had a superset of JCL function, providing a
> JCL-to-replacement
> translation utility would allow discarding direct support for JCL.
>
> >-Original Message-
> >From: John Melcher, Jr
> >Sent: Monday, July 2, 2018 10:46 AM
> >
> >Once upon a time a LONG time ago this was a GUIDE requirement. It was
> >voted down due to the amount of automated systems that generated JCL.
> >You'd have to keep JCL, probably forever, because of those systems.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
How about something like this?
Use REXX syntax and a JCL host command with JCL-like semantics:
/* REXX */
arg String /* From SUBMIT or start task command. */
"jcl job myjob: (acct),'john smith',class=t,msgclass=h,notify="userid()
"jcl exec pgm=myprog,parm="date("s")
"jcl sysprint: dd sysout=*"
"jcl sysin dd *"
"jcl data" String
...
The JCL host command could create the exact same control blocks as the
existing JCL statements today, but not begin execution. When the REXX exec
exited, ENQs would be processed as now, followed by the current processing,
including step execution, and cleanup. All exit/interfaces would be
preserved so that third-party software would still work unchanged.
OREXXMan
JCL is the buggy whip of 21st century computing. Stabilize it.
Put Pipelines in the z/OS base. Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.
On Mon, Jul 2, 2018 at 2:26 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote:
>
> >Oh my gosh, you would have to maintain JCL forever for that and a dozen
> other reasons.
> >
> >BUT! Conceivably ... conceivably ... you might stabilize it and do
> everything new in Rexx going forward.
> >
> If the replacement had a superset of JCL function, providing a
> JCL-to-replacement
> translation utility would allow discarding direct support for JCL.
>
> >-Original Message-
> >From: John Melcher, Jr
> >Sent: Monday, July 2, 2018 10:46 AM
> >
> >Once upon a time a LONG time ago this was a GUIDE requirement. It was
> >voted down due to the amount of automated systems that generated JCL.
> >You'd have to keep JCL, probably forever, because of those systems.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting (was: JCL ERROR : IGD01022I)
AFAIK, I have never used KOI8-R; I can't speak to what m$ outhouse may have
done behind my back. Maybe it copied the charset from the message I was
responding to?
Do you have human beings doing had encoding of messages? If not, then I'm
obviously talking about software.
Alas, while I know of validators for HTML and CSS, I don't know of any for
e-mail.
Cut-and-paste is beyond the scope of any RFC. However, the considerations are
pretty clear; if the text has a New Line (LF for Eunix, CRLF for windows) then
use a hard NL; if you split due to length, use a soft NL. Follow that and the
rules for space stuffing and you get the code intact at the other end. Break
them and all bets are off.
If the receiver does not support F=F then he will get extraneous line breaks; I
can't imagine what idiocy would cause extraneous line wrapping.
BTW, the webmail application for this e-mail account uses m$ lookout, and I
would not be surprised by any RFC violation that turns up.
--
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: Monday, July 2, 2018 2:16 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Formatting (was: JCL ERROR : IGD01022I)
(Yaay! You're no longer using koi8-r!)
On Mon, 2 Jul 2018 17:06:08 +, Seymour J Metz wrote:
>Implementing any new RFC is a big order. If the mail clients on both ends
>implement RFC 3676, then cut-and-paste works. If a brain dead application
>simply slaps in format=flowed without following the specifications in the RFC,
>then blame that application. Again, do you know of any problem when both ends
>actually adhere to the specifications?
>
o By "the mail clients on both ends" do you mean only the software, or do
you mean to include the human beings? It is not practical to expect human
beings to conform all requirements of RFC 3676.
o Is there an available validator and data suite for format-flowed for both
sending and receiving ends? Human eyeball validation is impractical and
error-prone. (And quis custodiet ipsos custodes?)
o If such a validator were to exist, to whom would one report deviations?
What's the realistic likelihood of resolutions other than "WAD"?
o Does RFC 3676 guarantee round-trip integrity? Ed should be able to
copy-and-past his Rexx snippet and Don to extract it, byte-for-byte
identical to the original. Otherwise, the specification is a broken design.
Format=flowed had two (more?) design objectives:
o Support for comfortable viewing on hand-held fondleslabs.
o Support for word processors which reserve CRLF for paragraph separation.
These are pretty irrelevant to computer languages. Esmie's JCL was illegible
to Lizette; Ed's Rexx was illegible to Don.
If format=flowed imposes no requirement on the sending human being, it
SHOULD be possible to move all the flow-function from the sending MUA
to the receiving MUA and the receiving human being should be given a
{FLOWED|FIXED} button for viewing and extracting code respectively.
"Save as File" would suffice if that file could be guaranteed identical to
what the originator attached.
Many user agents do not allow disabling of "format=flowed".
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?
I don't think I can accept an RFE on this one - the documentation clearly shows it should work :-) That and we need it to work -- Lionel B. Dyck (Contractor) < Mainframe Systems Programmer – RavenTek Solution Partners -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, July 02, 2018 1:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ? On Mon, 2 Jul 2018 17:26:00 +, Dyck, Lionel B. (RavenTek) wrote: >The use of VOL=SER=xx works but that is only useful for the 1st data set >being copied. I've tried variations of ,'s also without success. > >Time for a PMR :-) > What if they tell you that has to be an RFE? (I suppose that if there is a documented function that simply doesn't work, PMR should be accepted.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote: >Oh my gosh, you would have to maintain JCL forever for that and a dozen other >reasons. > >BUT! Conceivably ... conceivably ... you might stabilize it and do everything >new in Rexx going forward. > If the replacement had a superset of JCL function, providing a JCL-to-replacement translation utility would allow discarding direct support for JCL. >-Original Message- >From: John Melcher, Jr >Sent: Monday, July 2, 2018 10:46 AM > >Once upon a time a LONG time ago this was a GUIDE requirement. It was >voted down due to the amount of automated systems that generated JCL. >You'd have to keep JCL, probably forever, because of those systems. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?
On Mon, 2 Jul 2018 17:26:00 +, Dyck, Lionel B. (RavenTek) wrote: >The use of VOL=SER=xx works but that is only useful for the 1st data set >being copied. I've tried variations of ,'s also without success. > >Time for a PMR :-) > What if they tell you that has to be an RFE? (I suppose that if there is a documented function that simply doesn't work, PMR should be accepted.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting (was: JCL ERROR : IGD01022I)
(Yaay! You're no longer using koi8-r!)
On Mon, 2 Jul 2018 17:06:08 +, Seymour J Metz wrote:
>Implementing any new RFC is a big order. If the mail clients on both ends
>implement RFC 3676, then cut-and-paste works. If a brain dead application
>simply slaps in format=flowed without following the specifications in the RFC,
>then blame that application. Again, do you know of any problem when both ends
>actually adhere to the specifications?
>
o By "the mail clients on both ends" do you mean only the software, or do
you mean to include the human beings? It is not practical to expect human
beings to conform all requirements of RFC 3676.
o Is there an available validator and data suite for format-flowed for both
sending and receiving ends? Human eyeball validation is impractical and
error-prone. (And quis custodiet ipsos custodes?)
o If such a validator were to exist, to whom would one report deviations?
What's the realistic likelihood of resolutions other than "WAD"?
o Does RFC 3676 guarantee round-trip integrity? Ed should be able to
copy-and-past his Rexx snippet and Don to extract it, byte-for-byte
identical to the original. Otherwise, the specification is a broken design.
Format=flowed had two (more?) design objectives:
o Support for comfortable viewing on hand-held fondleslabs.
o Support for word processors which reserve CRLF for paragraph separation.
These are pretty irrelevant to computer languages. Esmie's JCL was illegible
to Lizette; Ed's Rexx was illegible to Don.
If format=flowed imposes no requirement on the sending human being, it
SHOULD be possible to move all the flow-function from the sending MUA
to the receiving MUA and the receiving human being should be given a
{FLOWED|FIXED} button for viewing and extracting code respectively.
"Save as File" would suffice if that file could be guaranteed identical to
what the originator attached.
Many user agents do not allow disabling of "format=flowed".
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Oh my gosh, you would have to maintain JCL forever for that and a dozen other reasons. BUT! Conceivably ... conceivably ... you might stabilize it and do everything new in Rexx going forward. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Melcher, Jr Sent: Monday, July 2, 2018 10:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: REXX as JCL replacement Once upon a time a LONG time ago this was a GUIDE requirement. It was voted down due to the amount of automated systems that generated JCL. You'd have to keep JCL, probably forever, because of those systems. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?
JCL and Connect:Direct syntax, while similar are not the same :-) -- Lionel B. Dyck (Contractor) < Mainframe Systems Programmer – RavenTek Solution Partners -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Beaver Sent: Monday, July 02, 2018 12:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ? Suggestion Code the parms on a DD statement and once you have that working transfer it to the CD COPY Statement -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dyck, Lionel B. (RavenTek) Sent: Monday, July 2, 2018 10:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ? Using C:D 5.2 and yes I had tried that :-) The 'error' message, if that is what you want to call it, claims invalid VOL=SER= usage. Banging head against the wall removes the pain of trying to figure this out but that is only temporary. -- Lionel B. Dyck (Contractor) < Mainframe Systems Programmer – RavenTek Solution Partners -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, July 02, 2018 9:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Connect:Direct and VOL=REF ? Dyck, Lionel B. (RavenTek) wrote: >After pouring thru the connect:direct pubs and finding that REF= is support, >I've not been able to find the correct syntax to do a VOL=REF=dsn within a >Connect:Direct Proc on the TO parameters. >Can anyone offer any suggestions/advice/direction? >The documented syntax is: >VOL = ( [PRIVATE],[RETAIN] ,[volume-sequence-no] >,[volume-count] >,[SER = (serial-no[,serial-no,...] ) ] ) | ( [SER = (serial-no, >[serial-no,...] ) | REF = dsn]) >We've tried: >Vol=ref=dsn >Vol=(ref=dsn) >Vol=ser=(ref=dsn) According to what you post and my copy of the C:D PDF doc I have, after a lot of trimming that looong and hard to read syntax diagram, ... try Vol=(ref=dsn) , but you have done that??? If not working, what version of C:D do you have? Do you see any error message(s)? Are you using C:D batch or online? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?
Suggestion Code the parms on a DD statement and once you have that working transfer it to the CD COPY Statement -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dyck, Lionel B. (RavenTek) Sent: Monday, July 2, 2018 10:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ? Using C:D 5.2 and yes I had tried that :-) The 'error' message, if that is what you want to call it, claims invalid VOL=SER= usage. Banging head against the wall removes the pain of trying to figure this out but that is only temporary. -- Lionel B. Dyck (Contractor) < Mainframe Systems Programmer – RavenTek Solution Partners -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, July 02, 2018 9:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Connect:Direct and VOL=REF ? Dyck, Lionel B. (RavenTek) wrote: >After pouring thru the connect:direct pubs and finding that REF= is support, >I've not been able to find the correct syntax to do a VOL=REF=dsn within a >Connect:Direct Proc on the TO parameters. >Can anyone offer any suggestions/advice/direction? >The documented syntax is: >VOL = ( [PRIVATE],[RETAIN] ,[volume-sequence-no] >,[volume-count] >,[SER = (serial-no[,serial-no,...] ) ] ) | ( [SER = (serial-no, >[serial-no,...] ) | REF = dsn]) >We've tried: >Vol=ref=dsn >Vol=(ref=dsn) >Vol=ser=(ref=dsn) According to what you post and my copy of the C:D PDF doc I have, after a lot of trimming that looong and hard to read syntax diagram, ... try Vol=(ref=dsn) , but you have done that??? If not working, what version of C:D do you have? Do you see any error message(s)? Are you using C:D batch or online? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
REXX as JCL replacement
Once upon a time a LONG time ago this was a GUIDE requirement. It was voted down due to the amount of automated systems that generated JCL. You'd have to keep JCL, probably forever, because of those systems. -- This message (and reply) was read by Google and the NSA. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?
The use of VOL=SER=xx works but that is only useful for the 1st data set being copied. I've tried variations of ,'s also without success. Time for a PMR :-) -- Lionel B. Dyck (Contractor) < Mainframe Systems Programmer – RavenTek Solution Partners -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, July 02, 2018 12:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ? On Mon, 2 Jul 2018 10:31:58 -0600, Roger Bolan wrote: >The syntax you showed makes me think that preceding commas are required. > That's what it seems to say, but does it mean it? Is this JCL, or an attempt to replicate JCL syntax? I can produce from this either: VOL = ( , , , SER = ( serial-no[,serial-no,...] ) ) or: VOL = ( REF = dsn ) (the parentheses are not indicated as optional.) But the OP says he has tried the latter and failed. RCF? "Enny fool kin plainly see what it means." is not polished documentation. >> >The documented syntax is: >> >> >VOL = ( [PRIVATE],[RETAIN] ,[volume-sequence-no] >> >,[volume-count] >> >,[SER = (serial-no[,serial-no,...] ) ] ) | ( [SER = (serial-no, >> >[serial-no,...] ) | REF = dsn]) (Once, when I coded some SMP/E control statements intended for customers, I used blanks as token separators rather than commas. A reviewer marked me down for that; it wasn't documented. I went to RCF, saying that a "," should appear as "[,]" wherever the "," is optional. IBM took the easy out by adding a statement in the frontmatter of the Ref. that commas appeaing in syntax diagrams are (usually?) optional.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?
On Mon, 2 Jul 2018 10:31:58 -0600, Roger Bolan wrote: >The syntax you showed makes me think that preceding commas are required. > That's what it seems to say, but does it mean it? Is this JCL, or an attempt to replicate JCL syntax? I can produce from this either: VOL = ( , , , SER = ( serial-no[,serial-no,...] ) ) or: VOL = ( REF = dsn ) (the parentheses are not indicated as optional.) But the OP says he has tried the latter and failed. RCF? "Enny fool kin plainly see what it means." is not polished documentation. >> >The documented syntax is: >> >> >VOL = ( [PRIVATE],[RETAIN] ,[volume-sequence-no] >> >,[volume-count] >> >,[SER = (serial-no[,serial-no,...] ) ] ) | ( [SER = (serial-no, >> >[serial-no,...] ) | REF = dsn]) (Once, when I coded some SMP/E control statements intended for customers, I used blanks as token separators rather than commas. A reviewer marked me down for that; it wasn't documented. I went to RCF, saying that a "," should appear as "[,]" wherever the "," is optional. IBM took the easy out by adding a statement in the frontmatter of the Ref. that commas appeaing in syntax diagrams are (usually?) optional.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting (was: JCL ERROR : IGD01022I)
Implementing any new RFC is a big order. If the mail clients on both ends implement RFC 3676, then cut-and-paste works. If a brain dead application simply slaps in format=flowed without following the specifications in the RFC, then blame that application. Again, do you know of any problem when both ends actually adhere to the specifications? -- 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: Sunday, July 1, 2018 4:35 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Formatting (was: JCL ERROR : IGD01022I) On Sun, 1 Jul 2018 18:39:02 +, Seymour J Metz wrote: >> I consider RFC 3676 an abomination, totally unsuitable for posting code >> samples. > >Why? Do you know of any case where a properly behaving mail client mangles >code properly formatted with format=flowed? > "properly formatted" is a big order. Before the infestation of format=flowed an author was able to copy-and-paste a code snippet into a message and the recipient could copy-and-paste and run it. Content-transfer-encoding: 8bit, now well supported removed one incentive to encode. RFC 822 mandated a 1000-character limit on line length, ample for coding. The feckless innovation of an 80-character limit impelled a new motive for encoding. In the message to which you're replying I experimented with UTF-8 text; long lines; 8bit. A surfeit of caution and timid adherence to Postel's rule has made things harder. Email shouldn't pretend to be a publishing tool. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for IMS Sysprog
AOL. We don't need any ethnic slurs here. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Gord Tomlin Sent: Sunday, July 1, 2018 3:59 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Looking for IMS Sysprog On 2018-06-30 21:39, Beverly Caldwell wrote: > Unfortunately people with names like yours... Admins, can we take care of this please? -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://secure-web.cisco.com/13XLsGdlcBL3RNLKdurU13AgRCvDPDQG0pgt5o6WpFsr-wPrG0ctDUmln-3vQ-tE-nPkRVQ6OmU_lcw2RDTehhhfWCtSTX93dAgccAMbl9ucYeFt2qxc6QsYNlyZgiai-kQGUDETOxrAnbnFuSQziQqe3nVBDD4fD9EEmTPGvDGzbR2cFGZcytkSxQ-Mvsec0hSjVQFTT4IhhBMaPnzGnsGkNt7gb4xXFhHP896yVSochr_GsZVGbCyvPGc_O3KZlttpOTVP_aLa5Tuere6gB_5nOnvzfa67I0k7LpfMDQJiJ2mVH7E_fAjfqMuwhRJSwMCedg_eDsPnj_9B7DI1uHyl1kCeM0ftF_oPR8hxh5y4pGl_haaIlr-AVtbZWh7Dnbu9ixwmwf4__Tn8a6NtoRzkTGYg67Ho_S2FdAX29sVmYh8atw-f02dDexVHNIkLH/https%3A%2F%2Factionsoftware.com%2Fsupport%2F -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting
Well, your first two line don't have leading spaces and they didn't get warped
(sic).
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of Ed
Jaffe
Sent: Sunday, July 1, 2018 7:02 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Formatting
On 7/1/2018 11:39 AM, Seymour J Metz wrote:
>> I consider RFC 3676 an abomination, totally unsuitable for posting code
>> samples.
> Why? Do you know of any case where a properly behaving mail client mangles
> code properly formatted with format=flowed?
AFAIK, I've never had an issue posting code fragments on any list. I'm
gonna experiment with one right now randomly taken from our local REXX
library. What am I doing wrong? (Or right?)
/* REXX */
TSMRMM:
address tso
/* trace I */
"bpxbatch sh dsmadmc -id=mvs60 -pa=xx -displ=tab",
/* "q volhist begindate=TODAY-1 begintime=15:00:00" */ ,
/* "enddate=TODAY-1 endtime=23:00:00" */ ,
"q volhist begindate=today" ,
"> /tmp/tsmrmm.qvolhist"
if rc <> 0 then exit 8
"allocate dd(tsmrpt) path('/tmp/tsmrmm.qvolhist')",
"recfm(v) lrecl(1024) filedata(text) reuse"
if rc <> 0 then exit 8
volcount = 0
"execio * diskr tsmrpt (stem rptline. open finis"
do i=1 to rptline.0
do j = 1 to words(rptline.i)
if LEFT(WORD(rptline.i,j),6) = "BACKUP" |,
LEFT(WORD(rptline.i,j),3) = "STG" then,
do
do k=j to words(rptline.i)
if LEFT(WORD(rptline.i,k),4) = "3590" then,
do
volcount = volcount + 1
type.volcount = WORD(rptline.i,j)
dev.volcount = WORD(rptline.i,k)
vol.volcount = WORD(rptline.i,k+1)
leave k
end
end
leave j
end
end
end
do i=1 to volcount
say "VolHist:" type.i dev.i vol.i
select
when type.i = "STGNEW" |,
LEFT(type.i,6) = "BACKUP" then,
do
rmmcmd = "RMM CV" vol.i "STATUS(MASTER) HOLD",
"OWNER(TIVSM) RELEASEACTION(ERASE)"
address tso rmmcmd
cc = rc
say "Command:" rmmcmd
say "RetCode:" cc
rmmcmd = "RMM CV" vol.i "LOCATION(SHELF)"
if dev.i ="3590VAULT1" then,
rmmcmd = "RMM CV" vol.i "MANUALMOVE LOCATION(FRED)"
address tso rmmcmd
cc = rc
say "Command:" rmmcmd
say "RetCode:" cc
end
when type.i = "STGDELETE" then,
do
rmmcmd = "RMM CV" vol.i "AUTOMOVE NOHOLD"
address tso rmmcmd
cc = rc
say "Command:" rmmcmd
say "RetCode:" cc
rmmcmd = "RMM DV" vol.i "RELEASE"
.
. (etc)
.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://secure-web.cisco.com/1_BcG6hJIhFngMuip6DiZhrO-_CeTaF4D5RKuSJ-IOE0IDmfKjS9Hq4xkPjyAQFOSbMlIbql7nGzJgXaJ5ZmyNByiw29SVrH-xcdv7LNHcJN9h0fzdiTtDsGq0gnhExujSU3RTYKoikKwfW80FUn8xwFxchM578-1ddlOvfjCvfTxXeyxtvSUvctACfX_vpJroz7kYAqrkD8wLG0fDzyoQNh0LToKZ2z8bnmqfIBC1Mm5NsKH9_6BtjTTKK4fQndfMV2TUHoKlwNuf32LM2y-1TW39IaNeDMrvpk3kgEHUMtlEDSg1G3N2ToFY5pFKFtMfRy8LtqGUAcBkWJjNrwEUx4V2XIrO5u4YKrZrFCJkSRjuLZopoIHGuHYUARB90Si5JWnpiAS0mnGipwTKACjPPSFODSaG4lgbxGitJj7QrTRFs3yG1R75_Abhhotmd0e/https%3A%2F%2Fwww.phoenixsoftware.com%2F
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message:
Re: SHARE App - Still no St. Louis?
On 7/2/2018 6:07 AM, Michael Babcock wrote: I still don’t see St. Louis in the SHARE app. Is that available yet or .? July 9th is the currently scheduled mobile app launch date... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting
> This code looks fine. My experience in posting to IBM-MAIN is that spaces at
> the beginning *or end*
> of a line allows the data to look fine. But truncating both leading and
> trailing spaces causes the
>List processor to flow lines up to the next 'break',
That sounds seriously b0rken. Can that behavior be turned off, or is it hard
wired.
BTW, your line 1 -3 appear fine.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Jesse 1 Robinson
Sent: Sunday, July 1, 2018 7:37 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Formatting
This code looks fine. My experience in posting to IBM-MAIN is that spaces at
the beginning *or end* of a line allows the data to look fine. But truncating
both leading and trailing spaces causes the List processor to flow lines up to
the next 'break', which may be a totally blank line. I try to copy lines from,
say, syslog, to include trailing blanks. If there are none on a particular
line, I hit the space bar after the last character.
Sending notes internally with the company does not involve these issues.
These lines have no leading or trailing blanks.
line 1 typed in
line 2 typed in
line 3 typed in
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Ed Jaffe
Sent: Sunday, July 01, 2018 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Formatting
On 7/1/2018 11:39 AM, Seymour J Metz wrote:
>> I consider RFC 3676 an abomination, totally unsuitable for posting
>> code samples.
> Why? Do you know of any case where a properly behaving mail client mangles
> code properly formatted with format=flowed?
AFAIK, I've never had an issue posting code fragments on any list. I'm gonna
experiment with one right now randomly taken from our local REXX library. What
am I doing wrong? (Or right?)
/* REXX */
TSMRMM:
address tso
/* trace I */
"bpxbatch sh dsmadmc -id=mvs60 -pa=xx -displ=tab",
/* "q volhist begindate=TODAY-1 begintime=15:00:00" */ ,
/* "enddate=TODAY-1 endtime=23:00:00" */ ,
"q volhist begindate=today" ,
"> /tmp/tsmrmm.qvolhist"
if rc <> 0 then exit 8
"allocate dd(tsmrpt) path('/tmp/tsmrmm.qvolhist')",
"recfm(v) lrecl(1024) filedata(text) reuse"
if rc <> 0 then exit 8
volcount = 0
"execio * diskr tsmrpt (stem rptline. open finis"
do i=1 to rptline.0
do j = 1 to words(rptline.i)
if LEFT(WORD(rptline.i,j),6) = "BACKUP" |,
LEFT(WORD(rptline.i,j),3) = "STG" then,
do
do k=j to words(rptline.i)
if LEFT(WORD(rptline.i,k),4) = "3590" then,
do
volcount = volcount + 1
type.volcount = WORD(rptline.i,j)
dev.volcount = WORD(rptline.i,k)
vol.volcount = WORD(rptline.i,k+1)
leave k
end
end
leave j
end
end
end
do i=1 to volcount
say "VolHist:" type.i dev.i vol.i
select
when type.i = "STGNEW" |,
LEFT(type.i,6) = "BACKUP" then,
do
rmmcmd = "RMM CV" vol.i "STATUS(MASTER) HOLD",
"OWNER(TIVSM) RELEASEACTION(ERASE)"
address tso rmmcmd
cc = rc
say "Command:" rmmcmd
say "RetCode:" cc
rmmcmd = "RMM CV" vol.i "LOCATION(SHELF)"
if dev.i ="3590VAULT1" then,
rmmcmd = "RMM CV" vol.i "MANUALMOVE LOCATION(FRED)"
address tso rmmcmd
cc = rc
say "Command:" rmmcmd
say "RetCode:" cc
end
when type.i = "STGDELETE" then,
do
rmmcmd = "RMM CV" vol.i "AUTOMOVE NOHOLD"
address tso rmmcmd
cc = rc
say "Command:" rmmcmd
say "RetCode:" cc
rmmcmd = "RMM DV" vol.i "RELEASE"
.
. (etc)
.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://secure-web.cisco.com/1ZMleawdw4Rr50ViFbXlqpgxgoK7CaQJInsqkvriPBoaIM1KLIrGrV1PQot4Drj9ss0f8pNPZTwa54-58Ct-bnQErKgAHc_SbhTs-ng_RCJnPSExBflNwQRVxqTD4sja1FaSBAoqZh99HR_D7Re6813VuQ8uVTi5C8RfnjyewwuRvUrPojwrYDQDjqvEM854TQkgfRVDovCfVjPWiqpH4qUl5eZuGFCF48s6RarS_iaf-Bu9ISOQ3fGKUoRd4n9k9PeANFv_zZDTw06dAZ9uTOaM84PE2-_CNrKG-sVVOB4_DUIoCEFO_NBbUyR-Ottn5_Brq-ptXT_i7TRcIZWb003Zcc7UP3kHvxbyghJi0JPYPGii1NxRL-uXvji30BcVZK3ofWZy0xlw5JuGsyYYU5NUNeihr38ttdsJVYzdchr9IHrGIF42aRZwUS_3VVGQ3/https%3A%2F%2Fwww.phoenixsoftware.com%2F
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
Re: SHARE App - Still no St. Louis?
Hi Michael, Hope all is well. SHARE St. Louis will not be present in the SHARE App until we are closer to the conference. However, in the meantime, the desktop version is available either from the menu of event.share.org under Agenda/Technical Agenda, or by using this url: https://events.share.org/Summer2018/Public/sessions.aspx. An email will be sent out to all registered SHARE St. Louis attendees once the SHARE St. Louis technical agenda is available on the SHARE App. Feel free to contact SHARE at shar...@share.org if you need any assistance. Thank you, Justin Bastin SHARE Secretary -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Michael Babcock Sent: Monday, July 2, 2018 7:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SHARE App - Still no St. Louis? I still don’t see St. Louis in the SHARE app. Is that available yet or .? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?
The syntax you showed makes me think that preceding commas are required. On Mon, Jul 2, 2018, 9:43 AM Dyck, Lionel B. (RavenTek) wrote: > Using C:D 5.2 and yes I had tried that :-) > > The 'error' message, if that is what you want to call it, claims invalid > VOL=SER= usage. > > Banging head against the wall removes the pain of trying to figure this > out but that is only temporary. > > -- > Lionel B. Dyck (Contractor) < > Mainframe Systems Programmer – RavenTek Solution Partners > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Elardus Engelbrecht > Sent: Monday, July 02, 2018 9:59 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: Connect:Direct and VOL=REF ? > > Dyck, Lionel B. (RavenTek) wrote: > > >After pouring thru the connect:direct pubs and finding that REF= is > support, I've not been able to find the correct syntax to do a VOL=REF=dsn > within a Connect:Direct Proc on the TO parameters. > > >Can anyone offer any suggestions/advice/direction? > > >The documented syntax is: > > >VOL = ( [PRIVATE],[RETAIN] ,[volume-sequence-no] > >,[volume-count] > >,[SER = (serial-no[,serial-no,...] ) ] ) | ( [SER = (serial-no, > >[serial-no,...] ) | REF = dsn]) > > >We've tried: > >Vol=ref=dsn > >Vol=(ref=dsn) > >Vol=ser=(ref=dsn) > > According to what you post and my copy of the C:D PDF doc I have, after a > lot of trimming that looong and hard to read syntax diagram, > > ... try Vol=(ref=dsn) , but you have done that??? > > If not working, what version of C:D do you have? > Do you see any error message(s)? > Are you using C:D batch or online? > > Groete / Greetings > Elardus Engelbrecht > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: Hot Topics (sort off ... ;-D )
Parker Solar Probe to be launched on or after 2018-07-31. Do not be silly Engelbrecht, Capt Kirk and crew will have gone (note the tense) far closer back in the 1960's. ; ^ ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Connect:Direct and VOL=REF ?
Using C:D 5.2 and yes I had tried that :-) The 'error' message, if that is what you want to call it, claims invalid VOL=SER= usage. Banging head against the wall removes the pain of trying to figure this out but that is only temporary. -- Lionel B. Dyck (Contractor) < Mainframe Systems Programmer – RavenTek Solution Partners -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, July 02, 2018 9:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Connect:Direct and VOL=REF ? Dyck, Lionel B. (RavenTek) wrote: >After pouring thru the connect:direct pubs and finding that REF= is support, >I've not been able to find the correct syntax to do a VOL=REF=dsn within a >Connect:Direct Proc on the TO parameters. >Can anyone offer any suggestions/advice/direction? >The documented syntax is: >VOL = ( [PRIVATE],[RETAIN] ,[volume-sequence-no] >,[volume-count] >,[SER = (serial-no[,serial-no,...] ) ] ) | ( [SER = (serial-no, >[serial-no,...] ) | REF = dsn]) >We've tried: >Vol=ref=dsn >Vol=(ref=dsn) >Vol=ser=(ref=dsn) According to what you post and my copy of the C:D PDF doc I have, after a lot of trimming that looong and hard to read syntax diagram, ... try Vol=(ref=dsn) , but you have done that??? If not working, what version of C:D do you have? Do you see any error message(s)? Are you using C:D batch or online? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Connect:Direct and VOL=REF ?
Dyck, Lionel B. (RavenTek) wrote: >After pouring thru the connect:direct pubs and finding that REF= is support, >I've not been able to find the correct syntax to do a VOL=REF=dsn within a >Connect:Direct Proc on the TO parameters. >Can anyone offer any suggestions/advice/direction? >The documented syntax is: >VOL = ( [PRIVATE],[RETAIN] ,[volume-sequence-no] >,[volume-count] >,[SER = (serial-no[,serial-no,...] ) ] ) | ( [SER = (serial-no, >[serial-no,...] ) | REF = dsn]) >We've tried: >Vol=ref=dsn >Vol=(ref=dsn) >Vol=ser=(ref=dsn) According to what you post and my copy of the C:D PDF doc I have, after a lot of trimming that looong and hard to read syntax diagram, ... try Vol=(ref=dsn) , but you have done that??? If not working, what version of C:D do you have? Do you see any error message(s)? Are you using C:D batch or online? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Connect:Direct and VOL=REF ?
After pouring thru the connect:direct pubs and finding that REF= is support, I've not been able to find the correct syntax to do a VOL=REF=dsn within a Connect:Direct Proc on the TO parameters. Can anyone offer any suggestions/advice/direction? The documented syntax is: VOL = ( [PRIVATE],[RETAIN] ,[volume-sequence-no] ,[volume-count] ,[SER = (serial-no[,serial-no,...] ) ] ) | ( [SER = (serial-no, [serial-no,...] ) | REF = dsn]) We've tried: Vol=ref=dsn Vol=(ref=dsn) Vol=ser=(ref=dsn) -- Lionel B. Dyck (Contractor) < Mainframe Systems Programmer - RavenTek Solution Partners -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Sun, Jul 1, 2018 at 12:12 PM Hobart Spitz wrote: > )Why don't we just skip the JCL, and write our jobs in REXX? The two > > Here, here!! Actually, there is one thing that is critical to retiring > JCL. It's a host command that allows a REXX program to list and wait for > all it's datasets and their enqueues to be available. This is not trivial, > so that's why no installation has taken it on. I don't know why IBM keeps > shoe-horning new features with big astonishment factors into JCL. z/OS is > the only major platform with a separate batch-only language. > > Anyone want to write sn RFE? > > I very much agree that JCL needs to be retired. It has a long and not-so-lustrous career. However, at least for me, one major thing which needs to be a critical consideration is restarting a "batch process" (aka REXX program, shell script). There needs to be someway which will, like CA-11 for instance, track what DSNs / UNIX files were created so that they can be automatically deleted when it is necessary. The new process must have a monitor which will keep track of which "step" equivalent has executed and be able to do something like a CA-11 restart. This becomes very complicated if the new processor can do looping. I can envision a REXX like environment where you can something like: /* REXX batch process */ ADDRESS BATCH /* activate the BATCH environment */ DSNPATTERN='SOMEHLQ.PROCESS.**.INPUT' "FINDDSNS (DSNPATTERN) (STEM DSN." /* Above does a catalog search for the DSNs described in DSNPATTERN */ /* DSN.0 == Number of DSNs found */ /* DSN.? (1 to DSN.0) == DSN found */ "ENQDSN (ISTEM DSN. OSTEM DDN. TIMEOUT 3600" /* Above does a SYSDSN enqueue on all DSNs in the stem, waiting up to 3600 seconds -- 1 hour */ /* ISTEM is a REXX "array" of DSNs which are input to the ENQDSN OSTEM is a parallel REXX "array" of DDNs which are allocated to the corresponding ISTEM input DSN. */ IF RC <> 0 THEN DO; /* ENQ FAILED -- nothing allocated */ SAY "ENQ TIMED OUT -- ABORTING" EXIT 16 /* END BATCH PROCESS WITH CC OF 16 */ END DO DDN_NUM = 1 TO DDN.0 "REALLOC SYSIN " DDN.DDN_NUM /* The above does a FREE on SYSIN (unless OPEN) and reallocates DDN.DDN_NUM to the DDN of SYSIN -- assumes DDN is harded coded in the program */ ADDRESS ATTACH "SOMEPGM PARM TO SOMEPGM" /* standard BATCH parameter list */ "CKPT" /* tell the BATCH environment to "checkpoint" somewhere */ END The above is just some "off the cuff" thoughts and a simple example of how something _might_ look. The BATCH environment is the replacement for JCL. It somehow communicates either with the JES system record checkpoint information for "restarting" the batch process if something happens. I didn't go into this because I simply don't have any good ideas. -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SHARE App - Still no St. Louis?
I still don’t see St. Louis in the SHARE app. Is that available yet or .? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 7-digit Job IDs
On Sat, 30 Jun 2018 06:27:59 -0700, Charles Mills wrote: >A search of Google for seven-digit jobs leads to headhunter sites. > I am sure you deserve a seven-digit salary -- but are not getting it :-( Try adding site:ibm.com to your Googling. Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF and millions of RSA keys
Arnold, Thank you very much for your help, I appreciate it. When talking about performance I also thouth about key "life management" like new key, key change, key delete. I don't expect it would be very frequent operation, but even that in multi-milion (10-20M rather than 2-3M) key database can be an issue. Regards -- Radoslaw Skorupka Lodz, Poland W dniu 2018-06-28 o 19:12, Todd Arnold pisze: Here are the answers from my friends on the ICSF development team. 1. Is it good idea to have millions of keys in PKDS? Would it be a problem for ICSF? VSAM limits seem to be not a problem, but maybe ICSF have some bottlenecks or limitations. There will be no problem for ICSF to store 2 to 3 million public keys in the PKDS. 2. Can I keep the keys out of PKDS, for example in DB2 table? Note, we talk about public key, so there is no big reason to keep it secret. For example: tell ICSF to check msg using given key value, instead of given key label. I remeber such solution is feasible for symmetric keys (the key was encrypted using Master Key). Yes, you can store the key tokens outside the PKDS. Callable services accept a label or key token. PKA public keys are in the clear, so there is no security issues. To be clear, I would only recommend keeping public keys outside the PKDS. Private keys should be maintained in the PKDS so they are properly reenciphered during a master key change. 3. What about performance? While DB2 table can be buffered, what about PKDS? Does it require I/O for every key use? During initialization, ICSF copies the PKDS into 64 bit storage. When a label is passed to a callable service, ICSF retrieves the key token from the in-store PKDS. No I/O is performed during the retrieval -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
