Re: COBOL5 and ceedump
>> And as for the "standard way" to cheat the Cobol table restriction (I'm no -- Peter Hunkeler >> Cobol programmer, sorry): Cheating is cheating. Shudder But it explains >> at >> least why IBM agreed to change the code. Thanks. >> > >Not cheating, accomplishing a business need despite the compiler limitations. No offence intended You're right, it is not cheeting, it's worse. It's relying on undocumented behaviour. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Confusing info about System Logger and GDPS K-systems
Maybe it depends on the GDPS level you are running, but in the V3.13 (and
several previous) manuals, appendix D states:
"As a consequence, and to avoid use of the System Logger on the Controlling
systems and any associated allocation of offload or staging data sets that must
be PPRCed for recovery purposes, the System Logger address space (IXGLOGR) is
cancelled on any Controlling system where it is found to be active. This is
initially performed during GDPS initialization on any Controlling system. Then
subsequently Monitor1 checks to ensure that the System Logger is not available
on any Controlling systems. Again, if it is found to be active, it will be
cancelled by GDPS."
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jesse 1 Robinson
Sent: 10 January, 2017 18:22
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Confusing info about System Logger and GDPS K-systems
I'm confused and mystified. We run GDPS for DR on a standalone sysplex. I'm not
sure what (if anything) we do with logger there, but the task is definitely
running on the K system.
IXG601I 09.19.25 LOGGER DISPLAY
SYSTEM LOGGER STATUS
SYSTEM SYSTEM LOGGER STATUS
--
X1 ACTIVE
.
.
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 Vernooij, Kees (ITOPT1) - KLM
Sent: Tuesday, January 10, 2017 4:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Confusing info about System Logger and GDPS K-systems
Hi Steve,
Thanks fort the hint.
The 2 apars seem (to me) to solve a situation caused by the new ALLOWACCESS(NO)
parameter.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Horein
Sent: 10 January, 2017 12:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Confusing info about System Logger and GDPS K-systems
These new function APARs may shed some light: OA50781 and OA50775 They talk
about secondary controlling systems (KSYS) being present within the SYSPLEX,
and IPL order.
I hope this helps!
On Tue, Jan 10, 2017 at 5:24 AM, Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:
> Hello,
>
> We run GDPS V3R13 and z/OS V2.2.
> I am reading the GDPS recommendations (in the GDPS/PPRC V3R13
> Installation and Customization Guide) about System Logger, which, as
> seems usual with each GDPS release, have changed again.
>
> Now I read some confusing and/or contradicting information (Ch 2.6).
>
> * The recommendation remains to not run System Logger on GDPS
> K-systems. GDPS will kill it if found.
>
> * There is a new IXGCNFxx member with parameters for System Logger.
>
> * The GDPS manual recommends ("To prevent XCFAS on the Controlling
> systems from allocating the LOGR CDS") to specify MANAGE
> ALLOWACCESS(NO) in IXGCNFxx on GDPS K-systems.
>
> What is the use of the last recommendation?
>
> * IXGCNFxx is used by System Logger, which is not started there,
> so it will never be processed.
>
> * Why would XCFAS access the LOGR CDS if not directed so by System
> Logger?
>
> * If yet so, how would XCFAS know about the XCFCNFxx restriction?
>
> DISPLAY LOGGER,IXGCNF,MANAGE
> IXG602I DISPLAY LOGGER COMMAND NOT PROCESSED, THE SYSTEM LOGGER IS NOT
> ACTIVE.
>
> Am I missing something?
>
> Regards,
> Kees.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to this
e-mail or attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately by return
e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission of
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered number
33014286
--
Re: "task level" TIOT & XTIOT? A crazy thought?
I was only giving thoughts on how COBOL might support something similar to the PL/I example. Beyond that I have not given the issue a moment of thought, as I don't have my own personal use case(s) in mind to consider. If you have a better way at another "implementation layer" you are very welcome to submit an RFE for that. From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, January 10, 2017 5:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "task level" TIOT & XTIOT? A crazy thought? On Wed, 11 Jan 2017 00:07:19 +, Frank Swarbrick wrote: >I personally don't have a particular use for it, and thus would not myself >create an RFE requesting it. But based on what I've seen discussed here I was >thinking they were looking for something like ... > Tunnel vision! The feature should not be COBOL-specific. That's why I mentioned early in this thread "wrong implementation layer". -- 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: "task level" TIOT & XTIOT? A crazy thought?
On Tue, 10 Jan 2017 17:23:18 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: "task level" TIOT & XTIOT? A crazy thought?" (in <1554048328241551.wa.paulgboulderaim@listserv.ua.edu>): > On Tue, 10 Jan 2017 20:18:04 +, David W Noon wrote: [snip] >> So, saying "no code changes" is rather arbitrary. >> > New function requires new support. Changes would be needed at the > system layer such as ATTACH and OPEN; not at the application layer > such as Charles's example, FTP. But we are really discussing COBOL and its current limitation regarding dynamic DDNAME usage. Other programming languages don't have this limitation. > It's dreadfully wasteful for each application program that needs the facility > to duplicate the code to process the alternate DDNAME list. What list? I am suggesting that any DDNAME that cannot be specified at design time be made parametric. That is all that COBOL needs to handle dynamic DDNAMEs. Frank Swarbrick's message would indicate that this is in the 2014 ISO/ANSI standard for COBOL but has not yet been implemented by IBM. >> How do you know what my habits are? >> > OK, then, not habits. You make your biases disturbingly clear. > I suppose the recent U.S. political campaign established a new > standard of deportment. I don't understand this. What has the U.S. political campaign to do with me? Should I have put a smiley after what I thought was an obviously rhetorical question? >> When writing shell scripts, environment variables are inescapable as >> every shell variable is in the shell's environment. If all you write are >> shell scripts then everything looks like an environment variable. >> > There's a distinction at least in terminology. "Exported" variables are > called "environment variables"; ohers are simply called "shell variables". > The former are available in programs forked by the shell; the latter > are not. But all are visible within the script. Visibility is not the issue here. The issue that arises is that any given variable has only one instance within an address space for a COBOL (or similar, traditional) program. >> The PARM field is more akin to the argv[] strings fed into a C/C++ or >> Java program. At least COBOL allows for this to be handled in the >> LINKAGE SECTION of the DATA DIVISION. However, COBOL has not >> traditionally handled environment variables and has not really needed them. >> > You don't "really need" anything other than a Universal Turing Machine. > Higher level facilities make our jobs easier. Well, that's COBOL out the window. ... :-) >> ... Worse still, the environment >> variables are shared by all tasks in the address space, so we are back >> with the problem of dynamically providing a name to identify an >> allocated dataset. The upshot is that an environment variable of a given >> name (i.e. hard coded in the COBOL source) will be the same for all >> tasks in the address space, just like the DDNAME in the TIOT/SIOT. >> > No. spawn() with _BPX_SHAREAS=YES (an environment variable) can > support multiple processes, each with its own environment variables > and its own TCB in a single address space. This is z/OS-peculiar; > not customary over all UNIXes. > > Look at the specification of execve(): > int execve(const char *path, char *const argv[], char *const envp[]); > Simply, argv[] is a list of positional arguments; envp[] is a similar list of > keyword arguments. The caller has complete control of both. And how many COBOL programmers do you expect to use a variant of the POSIX standard API? [And how do we get them to use this with "no code changes"?] > You misunderstand the operation of _BPX_SHAREAS. Actually, I don't. It's just that we are focussed on COBOL here, and the POSIX API is not readily exploited in that language. All the languages that can readily exploit the POSIX API already have dynamic DDNAME handling. >> As coded, each calling task can choose a DDNAME, possibly returned by >> SVC99, to have the same subroutine process different datasets for >> different tasks -- possibly concurrently. >> > And where would you get the arguments to pass to SVC99? The calling program would supply the sample subroutine with a DDNAME after having done whatever SVC 99 processing might be necessary. The calling program might use an existing DD, or it could read in a DSN and use SVC 99, or any other allocation strategy one could dream up. Different callers could use different allocation strategies to allocate different datasets with different DDNAMEs, all to be processed by the same subroutine. > And how > would you preserve one of the aboriginal design objectives of OS/360: > the ability to ENQ all needed resources before job initiation to avoid > deadlocks. That went out the window with the arrival of MVS/370, which introduced SVC 99. >> I hope you now see why environment variables are not really a workable >> solution for multi-tasking address spaces. >> > Single addre
Re: "task level" TIOT & XTIOT? A crazy thought?
On Wed, 11 Jan 2017 00:07:19 +, Frank Swarbrick wrote: >I personally don't have a particular use for it, and thus would not myself >create an RFE requesting it. But based on what I've seen discussed here I was >thinking they were looking for something like ... > Tunnel vision! The feature should not be COBOL-specific. That's why I mentioned early in this thread "wrong implementation layer". -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "task level" TIOT & XTIOT? A crazy thought?
I personally don't have a particular use for it, and thus would not myself create an RFE requesting it. But based on what I've seen discussed here I was thinking they were looking for something like the following example: select my-file assign using my-file-name. 01 my-file-name pic x(8). *> Populate with the DDNAME to be associated with "my-file" perform with test after until my-file-name = low-values move low-values to my-file-name accept my-file-name if my-file-name = low-values exit perform end-if open input my-file perform process-my-file close my-file end-perform (yes, I used exit perform. :-) ) With JCL being something like this: //SYSIN DD * FILE1 FILE2 FILE3 FILE4 /* //FILE1 DD ... //FILE2 DD ... //FILE3 DD ... //FILE4 DD ... If this is what the OP was really looking for I'm not sure. Frank From: IBM Mainframe Discussion List on behalf of Bill Woodger Sent: Tuesday, January 10, 2017 4:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "task level" TIOT & XTIOT? A crazy thought? And what would you want in data-name-1? A DDNAME,like the PL/I? A data set name? A partial data set name (with some magic for full expansion)? Something else? What do you feel, with your selected option for data-name-1, would be some example uses for this? Again, for me, just because something is in COBOL 2014, doesn't naturally mean it should get Enterprise COBOL development resources assigned to it. Clearly, unlike in 1985, the number of "sites" using COBOL on Linux/Unix/Windows is greater than the number of Mainframe sites. COBOL 2014 and future developments of the COBOL Standard will reflect this. As you've pointed out previously, with XML, Json and UNBOUNDED, IBM is happy to be COBOL-85-with-extesnsions-from-2002-2014-plus-our-own. So, good choices from 2002/2014, yes. What is it that would make the ability to use a data-name in the ASSIGN good? On Tue, 10 Jan 2017 23:01:59 +, Frank Swarbrick wrote: >For whatever its worth, the latest COBOL Standard offers the following syntax, >which I believe meets this requirement at the language level: > > >SELECT file-name-1 ASSIGN USING data-name-1. > > >"3) The ASSIGN clause specifies the association of the file connector >referenced by file-name-1 to a physical file identified by device-name-1, >literal-1, or the content of the data item referenced by data-name-1. > >3b) When the USING phrase of the ASSIGN clause is specified, the file >connector referenced by file-name-1 is associated with a physical file >identified by the content of the data item referenced by data-name-1 in the >runtime element that executes the OPEN, SORT, or MERGE statement." > > >Someone want to open an RFE? > > >Frank -- 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: "task level" TIOT & XTIOT? A crazy thought?
And what would you want in data-name-1? A DDNAME,like the PL/I? A data set name? A partial data set name (with some magic for full expansion)? Something else? What do you feel, with your selected option for data-name-1, would be some example uses for this? Again, for me, just because something is in COBOL 2014, doesn't naturally mean it should get Enterprise COBOL development resources assigned to it. Clearly, unlike in 1985, the number of "sites" using COBOL on Linux/Unix/Windows is greater than the number of Mainframe sites. COBOL 2014 and future developments of the COBOL Standard will reflect this. As you've pointed out previously, with XML, Json and UNBOUNDED, IBM is happy to be COBOL-85-with-extesnsions-from-2002-2014-plus-our-own. So, good choices from 2002/2014, yes. What is it that would make the ability to use a data-name in the ASSIGN good? On Tue, 10 Jan 2017 23:01:59 +, Frank Swarbrick wrote: >For whatever its worth, the latest COBOL Standard offers the following syntax, >which I believe meets this requirement at the language level: > > >SELECT file-name-1 ASSIGN USING data-name-1. > > >"3) The ASSIGN clause specifies the association of the file connector >referenced by file-name-1 to a physical file identified by device-name-1, >literal-1, or the content of the data item referenced by data-name-1. > >3b) When the USING phrase of the ASSIGN clause is specified, the file >connector referenced by file-name-1 is associated with a physical file >identified by the content of the data item referenced by data-name-1 in the >runtime element that executes the OPEN, SORT, or MERGE statement." > > >Someone want to open an RFE? > > >Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "task level" TIOT & XTIOT? A crazy thought?
On Tue, 10 Jan 2017 20:18:04 +, David W Noon wrote: >On Tue, 10 Jan 2017 13:06:14 -0600, Paul Gilmartin wrote: >>> >>> Simply use PL/I with the TITLE() option on the OPEN statement. ... >>> >>> If you really are wedded to COBOL, ask for the language to offer a new >>> facility in the ENVIRONMENT DIVISION, ... >>> >> No. The facility should be transparent to the attached program (no >> code changes). Charles isn't entitled to alter FTP to meet his needs. > >The existing code cannot deal with a single DDNAME being used for >multiple, distinct datasets in the same address space. The existing code >base handles its current working practices quite adequately, but new >functionality typically cannot be implemented without code changes. > >So, saying "no code changes" is rather arbitrary. > New function requires new support. Changes would be needed at the system layer such as ATTACH and OPEN; not at the application layer such as Charles's example, FTP. It's dreadfully wasteful for each application program that needs the facility to duplicate the code to process the alternate DDNAME list. >>> This is far more straightforward than fiddling with multiple TIOT, SIOT, >>> DSAB, etc. This also avoids the filth known as environment variables. >>> >> Why do you call a potentially effective approach that doesn't match your >> habits "filth". > >How do you know what my habits are? > OK, then, not habits. You make your biases disturbingly clear. I suppose the recent U.S. political campaign established a new standard of deportment. >> But environment variables are merely an additional PARM ... > >I am very familiar with environment variables and have been for over 25 >years. That still doesn't mean I particularly like them, even in >languages used more frequently than COBOL on POSIX platforms. > >When writing shell scripts, environment variables are inescapable as >every shell variable is in the shell's environment. If all you write are >shell scripts then everything looks like an environment variable. > There's a distinction at least in terminology. "Exported" variables are called "environment variables"; ohers are simply called "shell variables". The former are available in programs forked by the shell; the latter are not. >The PARM field is more akin to the argv[] strings fed into a C/C++ or >Java program. At least COBOL allows for this to be handled in the >LINKAGE SECTION of the DATA DIVISION. However, COBOL has not >traditionally handled environment variables and has not really needed them. > You don't "really need" anything other than a Universal Turing Machine. Higher level facilities make our jobs easier. > ... Worse still, the environment >variables are shared by all tasks in the address space, so we are back >with the problem of dynamically providing a name to identify an >allocated dataset. The upshot is that an environment variable of a given >name (i.e. hard coded in the COBOL source) will be the same for all >tasks in the address space, just like the DDNAME in the TIOT/SIOT. > No. spawn() with _BPX_SHAREAS=YES (an environment variable) can support multiple processes, each with its own environment variables and its own TCB in a single address space. This is z/OS-peculiar; not customary over all UNIXes. Look at the specification of execve(): int execve(const char *path, char *const argv[], char *const envp[]); Simply, argv[] is a list of positional arguments; envp[] is a similar list of keyword arguments. The caller has complete control of both. >> DDNAMEs seem to have had the noble objective of isolating a program >> from details of external data. In the context of concurrent processing, >> DDNAMEs "missed it by this much!" > >*Hard coded* DDNAMEs missed it by this much. > ... >Now, would you recommend that [the above] be re-coded to use an >environment variable for its DDN parameter, instead of using a program >variable as an argument? This would mean that all calling tasks within >the address space would use the same environment variable's contents to >build the parameter for fopen(), which means that all tasks would use >the same allocation of the same dataset. > You misunderstand the operation of _BPX_SHAREAS. >As coded, each calling task can choose a DDNAME, possibly returned by >SVC99, to have the same subroutine process different datasets for >different tasks -- possibly concurrently. > And where would you get the arguments to pass to SVC99? And how would you preserve one of the aboriginal design objectives of OS/360: the ability to ENQ all needed resources before job initiation to avoid deadlocks. >I hope you now see why environment variables are not really a workable >solution for multi-tasking address spaces. > Single address space jobs are an anachronism. They should have vanished with the advent of Virtual Memory and DAT, but the legacy of OS/360 through MVT perpetuated them. -- gil -- For IBM-MAI
Re: "task level" TIOT & XTIOT? A crazy thought?
For whatever its worth, the latest COBOL Standard offers the following syntax,
which I believe meets this requirement at the language level:
SELECT file-name-1 ASSIGN USING data-name-1.
"3) The ASSIGN clause specifies the association of the file connector
referenced by file-name-1 to a physical file identified by device-name-1,
literal-1, or the content of the data item referenced by data-name-1.
3b) When the USING phrase of the ASSIGN clause is specified, the file connector
referenced by file-name-1 is associated with a physical file identified by the
content of the data item referenced by data-name-1 in the runtime element that
executes the OPEN, SORT, or MERGE statement."
Someone want to open an RFE?
Frank
From: IBM Mainframe Discussion List on behalf of
David W Noon <013a910fd252-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, January 10, 2017 1:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "task level" TIOT & XTIOT? A crazy thought?
On Tue, 10 Jan 2017 13:06:14 -0600, Paul Gilmartin
(000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: "task
level" TIOT & XTIOT? A crazy thought?" (in
<2517422968801667.wa.paulgboulderaim@listserv.ua.edu>):
[snip]
> On Tue, 10 Jan 2017 18:26:27 +, David W Noon wrote:
>>
>> Simply use PL/I with the TITLE() option on the OPEN statement. ...
>>
>> If you really are wedded to COBOL, ask for the language to offer a new
>> facility in the ENVIRONMENT DIVISION, ...
>>
> No. The facility should be transparent to the attached program (no
> code changes). Charles isn't entitled to alter FTP to meet his needs.
The existing code cannot deal with a single DDNAME being used for
multiple, distinct datasets in the same address space. The existing code
base handles its current working practices quite adequately, but new
functionality typically cannot be implemented without code changes.
So, saying "no code changes" is rather arbitrary.
>> This is far more straightforward than fiddling with multiple TIOT, SIOT,
>> DSAB, etc. This also avoids the filth known as environment variables.
>>
> Why do you call a potentially effective approach that doesn't match your
> habits "filth".
How do you know what my habits are?
> But environment variables are merely an additional PARM
> (see the specification of the exec() syscall) and no more transparent than
> the alternate DDNAME list (filth?) as a second PARM.
I am very familiar with environment variables and have been for over 25
years. That still doesn't mean I particularly like them, even in
languages used more frequently than COBOL on POSIX platforms.
When writing shell scripts, environment variables are inescapable as
every shell variable is in the shell's environment. If all you write are
shell scripts then everything looks like an environment variable.
The PARM field is more akin to the argv[] strings fed into a C/C++ or
Java program. At least COBOL allows for this to be handled in the
LINKAGE SECTION of the DATA DIVISION. However, COBOL has not
traditionally handled environment variables and has not really needed them.
I view adding environment variables to COBOL as being like putting
high-octane gasoline into a diesel engine -- it might sound "way kewl"
but the results will not be pretty. Worse still, the environment
variables are shared by all tasks in the address space, so we are back
with the problem of dynamically providing a name to identify an
allocated dataset. The upshot is that an environment variable of a given
name (i.e. hard coded in the COBOL source) will be the same for all
tasks in the address space, just like the DDNAME in the TIOT/SIOT.
> DDNAMEs seem to have had the noble objective of isolating a program
> from details of external data. In the context of concurrent processing,
> DDNAMEs "missed it by this much!"
*Hard coded* DDNAMEs missed it by this much.
The functionally richer programming languages (PL/I, assembler) have
always allowed a program to specify the DDNAME field of a DCB or ACB at
run time. This has allowed a DDNAME to be fed in from various sources at
run time.
The missing capability here is with the COBOL language, and the
extension I recommended would be a simple and effective way of adding
it, while adhering to existing coding culture in COBOL.
Since you have written in the past that you don't write assembler, I
shall infer that you don't write PL/I either. So I will offer some
sample code in C, in the hope that your love of POSIX platforms has made
you familiar with that language.
#include
#include
void read_some_text(const char * DDN, char ** text_buffer)
{
char dd_string[16];
strcpy(dd_string, "DDNAME:");
strncat(dd_string, DDN, 8): /* DD names are at most 8 bytes. */
FILE * input_file = fopen(dd_string,"rt");
/* Process file. */
. . .
fclose(input_file);
return;
}
Now, would you recommend that the above be re-coded to use an
environment variable for its DDN param
Re: "task level" TIOT & XTIOT? A crazy thought?
On Tue, 10 Jan 2017 09:30:40 -0800, Charles Mills wrote: >Agree, agree, agree! >The single TIOT is a limit to "virtualization." ... > >To give a practical example, it might be nice to write an executive that would >ATTACH multiple FTP clients, so one could run a bunch of related file >transfers in parallel. But the FTP client program does not allow the >overriding of 'INPUT' and 'OUTPUT' as DD names, so the lack of independent >TIOTs precludes this idea. > Use UNIX System Services, as in (tested): user@OS/390.25.00: cat ftpdemo set -x ... ( ftp $Host1 >log1
Re: "task level" TIOT & XTIOT? A crazy thought?
On Tue, 10 Jan 2017 13:06:14 -0600, Paul Gilmartin
(000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: "task
level" TIOT & XTIOT? A crazy thought?" (in
<2517422968801667.wa.paulgboulderaim@listserv.ua.edu>):
[snip]
> On Tue, 10 Jan 2017 18:26:27 +, David W Noon wrote:
>>
>> Simply use PL/I with the TITLE() option on the OPEN statement. ...
>>
>> If you really are wedded to COBOL, ask for the language to offer a new
>> facility in the ENVIRONMENT DIVISION, ...
>>
> No. The facility should be transparent to the attached program (no
> code changes). Charles isn't entitled to alter FTP to meet his needs.
The existing code cannot deal with a single DDNAME being used for
multiple, distinct datasets in the same address space. The existing code
base handles its current working practices quite adequately, but new
functionality typically cannot be implemented without code changes.
So, saying "no code changes" is rather arbitrary.
>> This is far more straightforward than fiddling with multiple TIOT, SIOT,
>> DSAB, etc. This also avoids the filth known as environment variables.
>>
> Why do you call a potentially effective approach that doesn't match your
> habits "filth".
How do you know what my habits are?
> But environment variables are merely an additional PARM
> (see the specification of the exec() syscall) and no more transparent than
> the alternate DDNAME list (filth?) as a second PARM.
I am very familiar with environment variables and have been for over 25
years. That still doesn't mean I particularly like them, even in
languages used more frequently than COBOL on POSIX platforms.
When writing shell scripts, environment variables are inescapable as
every shell variable is in the shell's environment. If all you write are
shell scripts then everything looks like an environment variable.
The PARM field is more akin to the argv[] strings fed into a C/C++ or
Java program. At least COBOL allows for this to be handled in the
LINKAGE SECTION of the DATA DIVISION. However, COBOL has not
traditionally handled environment variables and has not really needed them.
I view adding environment variables to COBOL as being like putting
high-octane gasoline into a diesel engine -- it might sound "way kewl"
but the results will not be pretty. Worse still, the environment
variables are shared by all tasks in the address space, so we are back
with the problem of dynamically providing a name to identify an
allocated dataset. The upshot is that an environment variable of a given
name (i.e. hard coded in the COBOL source) will be the same for all
tasks in the address space, just like the DDNAME in the TIOT/SIOT.
> DDNAMEs seem to have had the noble objective of isolating a program
> from details of external data. In the context of concurrent processing,
> DDNAMEs "missed it by this much!"
*Hard coded* DDNAMEs missed it by this much.
The functionally richer programming languages (PL/I, assembler) have
always allowed a program to specify the DDNAME field of a DCB or ACB at
run time. This has allowed a DDNAME to be fed in from various sources at
run time.
The missing capability here is with the COBOL language, and the
extension I recommended would be a simple and effective way of adding
it, while adhering to existing coding culture in COBOL.
Since you have written in the past that you don't write assembler, I
shall infer that you don't write PL/I either. So I will offer some
sample code in C, in the hope that your love of POSIX platforms has made
you familiar with that language.
#include
#include
void read_some_text(const char * DDN, char ** text_buffer)
{
char dd_string[16];
strcpy(dd_string, "DDNAME:");
strncat(dd_string, DDN, 8): /* DD names are at most 8 bytes. */
FILE * input_file = fopen(dd_string,"rt");
/* Process file. */
. . .
fclose(input_file);
return;
}
Now, would you recommend that the above be re-coded to use an
environment variable for its DDN parameter, instead of using a program
variable as an argument? This would mean that all calling tasks within
the address space would use the same environment variable's contents to
build the parameter for fopen(), which means that all tasks would use
the same allocation of the same dataset.
As coded, each calling task can choose a DDNAME, possibly returned by
SVC99, to have the same subroutine process different datasets for
different tasks -- possibly concurrently.
I hope you now see why environment variables are not really a workable
solution for multi-tasking address spaces.
--
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "task level" TIOT & XTIOT? A crazy thought?
On Tue, 10 Jan 2017 12:38:22 -0600, John Mckown (john.archie.mck...@gmail.com) wrote about "Re: "task level" TIOT & XTIOT? A crazy thought?" (in ): > On Tue, Jan 10, 2017 at 12:26 PM, David W Noon < > 013a910fd252-dmarc-requ...@listserv.ua.edu> wrote: [snip] >> If you really are wedded to COBOL, ask for the language to offer a new >> facility in the ENVIRONMENT DIVISION, like: >> >> SELECT ASSIGN TO >> >> where the is something like: >> >>77WS-MY-DDNAMEPIC X(8). >> >> This can be the target of a text unit for SVC 99, or read from input, or >> passed in from a calling main program. > > Already taken, but not for WORKING STORAGE or the DD name. It can refer > to an existing DD name. If said DD does not exist, then it is the name of > the "environment variable" (UNIX concept) which contains information to do > an SVC 99. But the name remains the DD name, you can't override that, > unfortunately. That's why I said it would be a new facility in the language. The ASSIGN TO clause has always used the DDNAME, frequently decorated with hardware parameters. In recent years it can be the name of an environment variable that contains the dynalloc text for SVC 99. What I am saying is that allowing a program variable (WORKING-STORAGE or LINKAGE SECTION, or even a field in a file record) would extend COBOL to have most of the PL/I facilities of its TITLE() option or the C run-time library's fopen() call. >> This is far more straightforward than fiddling with multiple TIOT, SIOT, >> DSAB, etc. This also avoids the filth known as environment variables. I cannot stress the first sentence of the above paragraph too strongly. Adding a language facility so tightly tied to z/OS torpedoes program portability. It won't even work on z/VM, except in a z/OS guest. > too late, as stated above. Personally, I don't find environment variables > to be "filth". But I'm a long time UNIX user too. In a COBOL context, environment variables are total filth; the language has never had the syntax or semantics to handle them and has never needed them. I don't even like them that much when I am writing C/C++ or Python on a UNIX platform. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "task level" TIOT & XTIOT? A crazy thought?
On Tue, 10 Jan 2017 11:57:05 -0600, Greg Dyck wrote: >On 1/10/2017 11:30 AM, Charles Mills wrote: >> The single TIOT is a limit to "virtualization." > >Certainly the function could be useful. While conceptually it seems >easy to do, where the rubber meets the road in allocation, access >methods, SMF accounting, and more, it would be a very >disruptive/difficult function to implement since the TIOT is tied to the >currently active 'jobstep'. > The disruptiveness or difficulty of a posteriori implementation merely underlines the deficiency of a priori planning. Of course, I'm biased by the ease, simplicity, and transparency of POSIX shell redirection to achieve a similar function. On Tue, 10 Jan 2017 18:26:27 +, David W Noon wrote: > >Simply use PL/I with the TITLE() option on the OPEN statement. ... > >If you really are wedded to COBOL, ask for the language to offer a new >facility in the ENVIRONMENT DIVISION, ... > No. The facility should be transparent to the attached program (no code changes). Charles isn't entitled to alter FTP to meet his needs. >This is far more straightforward than fiddling with multiple TIOT, SIOT, >DSAB, etc. This also avoids the filth known as environment variables. > Why do you call a potentially effective approach that doesn't match your habits "filth". But environment variables are merely an additional PARM (see the specification of the exec() syscall) and no more transparent than the alternate DDNAME list (filth?) as a second PARM. DDNAMEs seem to have had the noble objective of isolating a program from details of external data. In the context of concurrent processing, DDNAMEs "missed it by this much!" -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RMM question
Most of our tape are logical volumes residing in an IBM VTS and they are SMS managed. Our RMM EDGRMMxx parm of RETAINBY is set to volume and we use RETENTION METHOD of VRSEL. I want a certain set of volumes to be managed by RETAINBY SET. Can this be done? FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Stupid pax -rf problem
On Tue, 10 Jan 2017 11:32:27 -0600, John McKown wrote: >On Tue, Jan 10, 2017 at 11:12 AM, R.S. wrote: > >> Of course I can (and I do) "cd /yyy/target/dir" before pax -r, but I can't >> believe it's the only option to skin the cat. > >You only want a clew (older English)? The clew is: look at the -s >parameter. And think strangely. > Rather than memorize all the options on the man page, I continue to rely on: ( cd /yyy/target/dir && pax -r ) (always "&&" rather than ";" lest I commit a typo in the "cd".) John suggested an option (which I've tried but not memorized) to do a sed-like transformation on output filenames. I found it even succeeds in extracting to "/dev/fd/1" so I can pipe to further filtering. I think there's a simpler option to modify the directory prefix. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "task level" TIOT & XTIOT? A crazy thought?
On Tue, Jan 10, 2017 at 12:26 PM, David W Noon < 013a910fd252-dmarc-requ...@listserv.ua.edu> wrote: > On Tue, 10 Jan 2017 07:27:12 -0600, John Mckown > (john.archie.mck...@gmail.com) wrote about ""task level" TIOT & XTIOT? A > crazy thought?" (in > ): > > [snip] > > So, have you ever wanted to run multiple, concurrent, executions of some > > program which does not accept an alternative DD name list? For instance, > > some in-house COBOL program. > > Simply use PL/I with the TITLE() option on the OPEN statement. This > allows the program to specify the DDNAME at run time. > > If you really are wedded to COBOL, ask for the language to offer a new > facility in the ENVIRONMENT DIVISION, like: > > SELECT ASSIGN TO > > where the is something like: > >77WS-MY-DDNAMEPIC X(8). > > This can be the target of a text unit for SVC 99, or read from input, or > passed in from a calling main program. > Already taken, but not for WORKING STORAGE or the DD name. It can refer to an existing DD name. If said DD does not exist, then it is the name of the "environment variable" (UNIX concept) which contains information to do an SVC 99. But the name remains the DD name, you can't override that, unfortunately. > > This is far more straightforward than fiddling with multiple TIOT, SIOT, > DSAB, etc. This also avoids the filth known as environment variables. > too late, as stated above. Personally, I don't find environment variables to be "filth". But I'm a long time UNIX user too. > > > Just running the idea up the flag pole to see who salutes. I don't really > > have much else to do any more. Just waiting for the axe. > > The waiting can be worse than the redundancy itself. ... :-( > -- > Regards, > > Dave [RLU #314465] > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > david.w.n...@googlemail.com (David W Noon) > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- There’s no obfuscated Perl contest because it’s pointless. —Jeff Polk Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "task level" TIOT & XTIOT? A crazy thought?
On Tue, 10 Jan 2017 07:27:12 -0600, John Mckown (john.archie.mck...@gmail.com) wrote about ""task level" TIOT & XTIOT? A crazy thought?" (in ): [snip] > So, have you ever wanted to run multiple, concurrent, executions of some > program which does not accept an alternative DD name list? For instance, > some in-house COBOL program. Simply use PL/I with the TITLE() option on the OPEN statement. This allows the program to specify the DDNAME at run time. If you really are wedded to COBOL, ask for the language to offer a new facility in the ENVIRONMENT DIVISION, like: SELECT ASSIGN TO where the is something like: 77WS-MY-DDNAMEPIC X(8). This can be the target of a text unit for SVC 99, or read from input, or passed in from a calling main program. This is far more straightforward than fiddling with multiple TIOT, SIOT, DSAB, etc. This also avoids the filth known as environment variables. > Just running the idea up the flag pole to see who salutes. I don't really > have much else to do any more. Just waiting for the axe. The waiting can be worse than the redundancy itself. ... :-( -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL5 and ceedump
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Peter Hunkeler > Sent: Tuesday, January 10, 2017 2:28 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: AW: Re: COBOL5 and ceedump > > > >A frequent, even standard way to get past the size limit of a COBOL array, or > more appropriately table, was to define more "empty" space after it. Since > subscript bounds checking was always turned off for performance reasons, > you could effectively address substantially larger than the size limit of any > single 01 item. > > > > I understand. I also read the head of the thread that Bill posted. > > > > It seems kind of ridiculous to me to justify all this with "less experienced > programmers". I remember when I was told how to program, I was told to > always make sure my coded does not go beyond the table. This is nothing > difficult to do. There is no excuse not to do it. > > > And as for the "standard way" to cheat the Cobol table restriction (I'm no > Cobol programmer, sorry): Cheating is cheating. Shudder But it explains at > least why IBM agreed to change the code. Thanks. > Not cheating, accomplishing a business need despite the compiler limitations. > > > > -- > Peter Hunkeler > > > > -- > 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: "task level" TIOT & XTIOT? A crazy thought?
On 1/10/2017 11:30 AM, Charles Mills wrote: The single TIOT is a limit to "virtualization." Certainly the function could be useful. While conceptually it seems easy to do, where the rubber meets the road in allocation, access methods, SMF accounting, and more, it would be a very disruptive/difficult function to implement since the TIOT is tied to the currently active 'jobstep'. Regards, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Stupid pax -rf problem
On Tue, Jan 10, 2017 at 11:12 AM, R.S. wrote: > The following scenario: > pax archive created in some directory, let's say /aaa/bbb (many files and > subdirectories here) > the resulting archive is /TEST.pax > > I'm able to restore the archive using the following command: > pax -r -peW -f /TEST.pax > > However the command above restores the archive in a *current directory*. > I want to provide a target directory as a command parameter, like > pax -r -peW -f /TEST.pax -some-magic-option:/yyy/target/dir > > Of course I can (and I do) "cd /yyy/target/dir" before pax -r, but I can't > believe it's the only option to skin the cat. > > Any clue? > You only want a clew (older English)? The clew is: look at the -s parameter. And think strangely. > > -- > Radoslaw Skorupka > Lodz, Poland > OK, I'll be nice. Try the command: pax -r -peW -s#^#/yyy/target/dir/# -f /TEST.pax You might want to use a "-l" before doing a "-r" just to see what "pax" will actually do. Basically the -s will "prepend" (the ^ is bregexp for "before start of string") the string "/yyy/targfet/dir/" to the front of whatever is in the pax. Make sure to include the trailing / in the directory of things likely won't work correctly. -- There’s no obfuscated Perl contest because it’s pointless. —Jeff Polk Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "task level" TIOT & XTIOT? A crazy thought?
Agree, agree, agree! The single TIOT is a limit to "virtualization." I could write an "executive" to run multiple application programs simultaneously as a single jobstep with separate TCBs. The usefulness of a general such solution is limited by the lack of independent DD's for each program. Yes, saying what Gil says differently, if each of the programs support DD override I could do it that way, but that's a big if. To give a practical example, it might be nice to write an executive that would ATTACH multiple FTP clients, so one could run a bunch of related file transfers in parallel. But the FTP client program does not allow the overriding of 'INPUT' and 'OUTPUT' as DD names, so the lack of independent TIOTs precludes this idea. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, January 10, 2017 8:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "task level" TIOT & XTIOT? A crazy thought? On Tue, 10 Jan 2017 07:27:12 -0600, John McKown wrote: > >So, have you ever wanted to run multiple, concurrent, executions of >some program which does not accept an alternative DD name list? For >instance, some in-house COBOL program. Wouldn't it be kind of nice to >be able to specify some parameter, such as NEWTIOT=YES so that the >program being attached would have its own, "private" TIOT & XTIOT, >which would then propogate to any of its children TCBs which did not have a >NEWTIOT=YES. >Hum, it might even be nice to be able to list which DDs are to be >"passed down", a bit like you can say whether or not to share a >specific SUBPOOL with a subtask. That might be nice for something like >SYSPRINT. > It has long been my perception that IBM has a penchant for providing valuable facilities at implementation layers that limit their usefulness. I consider the alternate DDNAME list an example. Rather, it should be an additional argment to ATTACH, implemented by code in ATTACH and OPEN, and quite transparent to the child task. And rather than positional it should have apparent/real DDNAME pairs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Confusing info about System Logger and GDPS K-systems
I'm confused and mystified. We run GDPS for DR on a standalone sysplex. I'm not
sure what (if anything) we do with logger there, but the task is definitely
running on the K system.
IXG601I 09.19.25 LOGGER DISPLAY
SYSTEM LOGGER STATUS
SYSTEM SYSTEM LOGGER STATUS
--
X1 ACTIVE
.
.
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 Vernooij, Kees (ITOPT1) - KLM
Sent: Tuesday, January 10, 2017 4:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Confusing info about System Logger and GDPS K-systems
Hi Steve,
Thanks fort the hint.
The 2 apars seem (to me) to solve a situation caused by the new ALLOWACCESS(NO)
parameter.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Horein
Sent: 10 January, 2017 12:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Confusing info about System Logger and GDPS K-systems
These new function APARs may shed some light: OA50781 and OA50775 They talk
about secondary controlling systems (KSYS) being present within the SYSPLEX,
and IPL order.
I hope this helps!
On Tue, Jan 10, 2017 at 5:24 AM, Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:
> Hello,
>
> We run GDPS V3R13 and z/OS V2.2.
> I am reading the GDPS recommendations (in the GDPS/PPRC V3R13
> Installation and Customization Guide) about System Logger, which, as
> seems usual with each GDPS release, have changed again.
>
> Now I read some confusing and/or contradicting information (Ch 2.6).
>
> * The recommendation remains to not run System Logger on GDPS
> K-systems. GDPS will kill it if found.
>
> * There is a new IXGCNFxx member with parameters for System Logger.
>
> * The GDPS manual recommends ("To prevent XCFAS on the Controlling
> systems from allocating the LOGR CDS") to specify MANAGE
> ALLOWACCESS(NO) in IXGCNFxx on GDPS K-systems.
>
> What is the use of the last recommendation?
>
> * IXGCNFxx is used by System Logger, which is not started there,
> so it will never be processed.
>
> * Why would XCFAS access the LOGR CDS if not directed so by System
> Logger?
>
> * If yet so, how would XCFAS know about the XCFCNFxx restriction?
>
> DISPLAY LOGGER,IXGCNF,MANAGE
> IXG602I DISPLAY LOGGER COMMAND NOT PROCESSED, THE SYSTEM LOGGER IS NOT
> ACTIVE.
>
> Am I missing something?
>
> Regards,
> Kees.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Stupid pax -rf problem
The following scenario: pax archive created in some directory, let's say /aaa/bbb (many files and subdirectories here) the resulting archive is /TEST.pax I'm able to restore the archive using the following command: pax -r -peW -f /TEST.pax However the command above restores the archive in a *current directory*. I want to provide a target directory as a command parameter, like pax -r -peW -f /TEST.pax -some-magic-option:/yyy/target/dir Of course I can (and I do) "cd /yyy/target/dir" before pax -r, but I can't believe it's the only option to skin the cat. Any clue? -- Radoslaw Skorupka Lodz, Poland --- 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.pl Są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.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: General question about address space
The case I know best is JES2, which now includes tasks JES2AUX and JES2MON. The classic single-task JES2 problem was a hang on one member of a MAS. All other systems complained about access to the checkpoint, while the hung system couldn't even respond to simple commands. It's hung, after all. A second address space--which is designed to depend on minimal resources--is in a better position to analyze and report on the problem, perhaps allowing recovery short of killing the wounded guy. . . 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 Lizette Koehler Sent: Tuesday, January 10, 2017 6:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: General question about address space If I understand your question. Take DFHSM. It can be one address space or multiple Address Spaces (MASH). The benefit to multiple address spaces is you could use WLM to control which one gets more or less priority in the system. So rather than one large DFHSM address space, you could have, as an example, DFHSM1 for Main processing and recalls, DFHSM2 for migrations and backups, DFHSM3 for Recovery. Then use WLM to set the priority on them. So Recalls get a high priority address space. Migrations or backup a low priority address space. Of course if I did not understand your question, then this is probably the wrong answer. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Peter > Sent: Tuesday, January 10, 2017 6:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: General question about address space > > Hi > > A product having one address space for monitoring various components > like network, Db2, CICS and multiple address space to monitor a single > component > > > Is there any advantage on having multiple address space compared with > sjngle address space ? > > Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Hidden Figures
On Jan 10, 2017, at 10:36 AM, Clark Morris wrote: > > 7070 was decimal. Do you mean 7090 which was 36 bit word binary? Yes, I mistyped it. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Hidden Figures
[Default] On 10 Jan 2017 05:48:59 -0800, in bit.listserv.ibm-main curtis@austin.utexas.edu (Pew, Curtis G) wrote: >My wife and I saw the movie Hidden Figures last Saturday, and I highly >recommend it. Mentioning this here seems appropriate, since an IBM 7070 and >FORTRAN play a significant role in the narrative. 7070 was decimal. Do you mean 7090 which was 36 bit word binary? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "task level" TIOT & XTIOT? A crazy thought?
On Tue, 10 Jan 2017 07:27:12 -0600, John McKown wrote: > >So, have you ever wanted to run multiple, concurrent, executions of some >program which does not accept an alternative DD name list? For instance, >some in-house COBOL program. Wouldn't it be kind of nice to be able to >specify some parameter, such as NEWTIOT=YES so that the program being >attached would have its own, "private" TIOT & XTIOT, which would then >propogate to any of its children TCBs which did not have a NEWTIOT=YES. >Hum, it might even be nice to be able to list which DDs are to be "passed >down", a bit like you can say whether or not to share a specific SUBPOOL >with a subtask. That might be nice for something like SYSPRINT. > It has long been my perception that IBM has a penchant for providing valuable facilities at implementation layers that limit their usefulness. I consider the alternate DDNAME list an example. Rather, it should be an additional argment to ATTACH, implemented by code in ATTACH and OPEN, and quite transparent to the child task. And rather than positional it should have apparent/real DDNAME pairs. I suggested this here before. An ISV employee reported that his product achieved the effect by screening SVCs, with some (unspecified) limitations. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Freeware SMP/E installable product
Potentially usermods that are in the public domain could qualify if you interpret "install" loosely. :-) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Tuesday, January 10, 2017 11:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Freeware SMP/E installable product W dniu 2017-01-10 o 17:16, Nathan Astle pisze: > Hi > > Are there any freeware product which uses SMP/E to install. There are several IBM products which are free of charge. While it's not the same as freeware, every legal z/OS user can download it and install. Majority of the products are available through ShopzSeries, but on the "z/OS downloads" page you'll find also some packages. The last one still require registration, but AFAIK nothing more. So, if you want something to play with SMP/E, voila. If not - what is your need? Of course some CBT free tools can also use SMP/E, but I don't remember any at the time. HTH Regards -- Radoslaw Skorupka Lodz, Poland --- 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.pl Są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.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych. -- 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: Freeware SMP/E installable product
Hi There was a freeware scheduler which uses SMP/E but I don't remember. Does anyone know ? On Jan 10, 2017 9:56 PM, "R.S." wrote: > W dniu 2017-01-10 o 17:16, Nathan Astle pisze: > >> Hi >> >> Are there any freeware product which uses SMP/E to install. >> > There are several IBM products which are free of charge. > While it's not the same as freeware, every legal z/OS user can download it > and install. > Majority of the products are available through ShopzSeries, but on the > "z/OS downloads" page you'll find also some packages. The last one still > require registration, but AFAIK nothing more. > > So, if you want something to play with SMP/E, voila. If not - what is your > need? > > Of course some CBT free tools can also use SMP/E, but I don't remember any > at the time. > > HTH > > Regards > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > --- > 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.pl > Są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.2016 r. kapitał zakładowy mBanku > S.A. (w całości wpłacony) wynosi 168.955.696 złotych. > > > -- > 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: Freeware SMP/E installable product
W dniu 2017-01-10 o 17:16, Nathan Astle pisze: Hi Are there any freeware product which uses SMP/E to install. There are several IBM products which are free of charge. While it's not the same as freeware, every legal z/OS user can download it and install. Majority of the products are available through ShopzSeries, but on the "z/OS downloads" page you'll find also some packages. The last one still require registration, but AFAIK nothing more. So, if you want something to play with SMP/E, voila. If not - what is your need? Of course some CBT free tools can also use SMP/E, but I don't remember any at the time. HTH Regards -- Radoslaw Skorupka Lodz, Poland --- 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.pl Są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.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Freeware SMP/E installable product
Nathan Astle wrote: Hi Are there any freeware product which uses SMP/E to install. Please point me Nathan Java for z/OS fits this description. You can order it from Shopz and get it over the net, on DVD, or on tape. -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Freeware SMP/E installable product
Hi Are there any freeware product which uses SMP/E to install. Please point me Nathan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error
Pommier, Rex wrote: >No I didn't need to use TOLerate. I'm assuming you meant TOL(ENQF). Ok. thanks, I was not sure what type of COPY you used, but thanks. > If I would need to use TOL(IOER) I have bigger problems. :-) Indeed. To tolerate IO errors is asking for trouble... I will not tolerate that specific usage of TOL(IOER). (sorry, pun intended.) Thanks Rex, you have cured my curiousity. I hope you can get your other production JES2 up and running on 2.2 (nice and WARM instead of ugly and COLD). ;-D Groete / Greetings Elardus Engelbrech -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: General question about address space
Liz you understood it correct On Jan 10, 2017 7:56 PM, "Lizette Koehler" wrote: > If I understand your question. > > Take DFHSM. It can be one address space or multiple Address Spaces > (MASH). The benefit to multiple address spaces is you could use WLM to > control which one gets more or less priority in the system. So rather than > one large DFHSM address space, you could have, as an example, DFHSM1 for > Main processing and recalls, DFHSM2 for migrations and backups, DFHSM3 for > Recovery. Then use WLM to set the priority on them. > > So Recalls get a high priority address space. Migrations or backup a low > priority address space. > > Of course if I did not understand your question, then this is probably the > wrong answer. > > Lizette > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Peter > > Sent: Tuesday, January 10, 2017 6:12 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: General question about address space > > > > Hi > > > > A product having one address space for monitoring various components like > > network, Db2, CICS and multiple address space to monitor a single > component > > > > > > Is there any advantage on having multiple address space compared with > sjngle > > address space ? > > > > Peter > > > > -- > 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: Hidden Figures
I had to explain the "HAL" name in 2001 A Space Odyssey, legend says it was a one-letter shift from IBM, but that was denied by the writers :-) We're so old the young generation can't even appreciate our fiction :-) Len Rugen University of Missouri Division of Information Technology Systems & Operations - Metrics & Automation Team From: IBM Mainframe Discussion List on behalf of Pew, Curtis G Sent: Tuesday, January 10, 2017 7:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Hidden Figures My wife and I saw the movie "Hidden Figures" last Saturday, and I highly recommend it. Mentioning this here seems appropriate, since an IBM 7070 and FORTRAN play a significant role in the narrative. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- 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: General question about address space
If I understand your question. Take DFHSM. It can be one address space or multiple Address Spaces (MASH). The benefit to multiple address spaces is you could use WLM to control which one gets more or less priority in the system. So rather than one large DFHSM address space, you could have, as an example, DFHSM1 for Main processing and recalls, DFHSM2 for migrations and backups, DFHSM3 for Recovery. Then use WLM to set the priority on them. So Recalls get a high priority address space. Migrations or backup a low priority address space. Of course if I did not understand your question, then this is probably the wrong answer. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter > Sent: Tuesday, January 10, 2017 6:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: General question about address space > > Hi > > A product having one address space for monitoring various components like > network, Db2, CICS and multiple address space to monitor a single component > > > Is there any advantage on having multiple address space compared with sjngle > address space ? > > Peter > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error
Elardus, No I didn't need to use TOLerate. I'm assuming you meant TOL(ENQF). If I would need to use TOL(IOER) I have bigger problems. :-) And I just looked it up, it appears that TOL(ENQF) isn't even a viable option on a COPY FULL command. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Tuesday, January 10, 2017 12:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error Pommier, Rex wrote: >I had the same thoughts over the weekend and messing with it this morning, I >discovered the problem. I had neglected to use the ALLD and ALLE parameters >in my DFDSS job to copy the spool and checkpoint volumes. So DFDSS dutifully >copied the pointers to "empty" datasets. Excellent! ALLEXCP and ALLDATA! Thats them. You need them to clone [all] your JES2 data. Perhaps a documentation update should be placed in JES2 migration guide and Program Directory about this? Oh, BTW, did you also need to use TOLERATE? Just curious. >Guessing I'm not going to forget this one! Neither me, I remember that I also burned my fingers badly during cloning of a system for testing out Y2K... ;-) Groete / Greetings Elardus Engelbrecht How many electrical engineers does it take to change a light bulb? We don't know yet, they're still waiting for a part. How many programmers does it take to change a light bulb? None - it is a hardware problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: General question about address space
Peter Historically there was an immediate expansion of the total amount of 31-bit private storage available to the product - these days with 64-bit storage functionality, the reason for horizontal private expansion (or use of dataspaces) is much reduced. There is also lots of architectural advantages to splitting logical functionality on the address space boundary, including ring-fencing resources and consumption. There are other external factors to consider as well, for example a program that does a CAF connect to DB2 or MQ cannot come from a re-usable address space. Rob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Sent: Tuesday, January 10, 2017 1:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: General question about address space Hi A product having one address space for monitoring various components like network, Db2, CICS and multiple address space to monitor a single component Is there any advantage on having multiple address space compared with sjngle address space ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 877.328.2932 ■ +1 781.577.4321 Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Hidden Figures
My wife and I saw the movie “Hidden Figures” last Saturday, and I highly recommend it. Mentioning this here seems appropriate, since an IBM 7070 and FORTRAN play a significant role in the narrative. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
"task level" TIOT & XTIOT? A crazy thought?
OK, I know that there can be multiple TIOTs in a single address space. I know this because the documentation the IEFUJI says that it can do I/O to a data set either by doing a DYNALLOC on it, or by putting the DD in the initiator procedure. So, have you ever wanted to run multiple, concurrent, executions of some program which does not accept an alternative DD name list? For instance, some in-house COBOL program. Wouldn't it be kind of nice to be able to specify some parameter, such as NEWTIOT=YES so that the program being attached would have its own, "private" TIOT & XTIOT, which would then propogate to any of its children TCBs which did not have a NEWTIOT=YES. Hum, it might even be nice to be able to list which DDs are to be "passed down", a bit like you can say whether or not to share a specific SUBPOOL with a subtask. That might be nice for something like SYSPRINT. Just running the idea up the flag pole to see who salutes. I don't really have much else to do any more. Just waiting for the axe. -- There’s no obfuscated Perl contest because it’s pointless. —Jeff Polk Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL5 and ceedump
Last I heard, SSRANGE was deprecated for production use due to high overhean. Yes, a deliberate area left specifically to catch any overflow and for no other purpose, similar to a patch-area. Technique arises before SSRANGE exists. If SSRANGE were subsequently used, it would/could catch the problem, but it is not as simple as the APAR text makes out (from memory of the text). So SSRANGE would "help" but not necessarily be sufficient, and remember that in cases the originally code is deliberately overflowing (to overcome an old compiler limitation). Then you get into "change that costs (development/testing/implementation) but achieves nothing, which is sometimes difficult (but important) to "sell" to management. Those who didn't buy (and who migrated early to V5+) reaped that whirlwind. Note that with V5+, the LE runtime option CHECK no longer influences anything. You can't deploy with SSRANGE(ON) and run with CHECK(OFF). Amusingly (to me anyway) people who run CHECK(ON) in Production complained about the additional "overhead" of the check for CHECK being ON or OFF. On Tue, 10 Jan 2017 04:10:12 -0600, Elardus Engelbrecht wrote: >Gibney, Dave wrote: > >>A frequent, even standard way to get past the size limit of a COBOL array, or >>more appropriately table, was to define more "empty" space after it. Since >>subscript bounds checking was always turned off for performance reasons, you >>could effectively address substantially larger than the size limit of any >>single 01 item. > >Hmmm, it reminds me of a sort of patch area? > >I'm curious, what about usage of SSRANGE compile option and CHECK(ON) runtime >option to avoid going over an array/table and getting an ABEND? Or will that >subscript bounds checking not help you here? > >I'm also puzzled by that APARs and the comments in this thread. (We're >still at COBOL v4, 5655-S71) > >Just following this thread out of curiousity. ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
General question about address space
Hi A product having one address space for monitoring various components like network, Db2, CICS and multiple address space to monitor a single component Is there any advantage on having multiple address space compared with sjngle address space ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OT? IBM makes patent record: 8,088 patents granted in 2016.
https://www-03.ibm.com/press/us/en/pressrelease/51353.wss -- There’s no obfuscated Perl contest because it’s pointless. —Jeff Polk Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [SURVEY] Who's using Java 8
Kirk, We currently use your Tomcat 7 port for dev but we're going to move to Jetty for technical reasons. Java 8 gives us better options WRT libraries. We can ditch Joda for the JRE datatime package and use modern techniques like lamdas. Not to mention the other reasons others have posted to my survey. Of course, we will have to implement our own login module and SAF support but Jetty has good support for that. One of the features I particularly liked about your Tomcat port was the zfile URL protocol handler. We will have to write one if we decide to use PDS data sets for config files. David, FYI, we recently updated our free z/OS port / packaging / enhancements to Apache Tomcat to include Tomcat 8, which requires Java 7. https://dovetail.com/products/tomcat.html Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Dec 21, 2016 at 9:18 AM, David Crayford wrote: We're currently developing a product with a web UI that uses a Java application server running on z/OS, either Tomcat or Jetty. We decided to use Java 7 because most sites probably have that installed already and having a dependency on Java 8 might be POC obstacle for some sites. But Java 8 has a lot of benefits. I'm wondering how common Java 8 is at your site? -- 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: Confusing info about System Logger and GDPS K-systems
Hi Steve,
Thanks fort the hint.
The 2 apars seem (to me) to solve a situation caused by the new ALLOWACCESS(NO)
parameter.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Horein
Sent: 10 January, 2017 12:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Confusing info about System Logger and GDPS K-systems
These new function APARs may shed some light: OA50781 and OA50775
They talk about secondary controlling systems (KSYS) being present within
the SYSPLEX, and IPL order.
I hope this helps!
On Tue, Jan 10, 2017 at 5:24 AM, Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:
> Hello,
>
> We run GDPS V3R13 and z/OS V2.2.
> I am reading the GDPS recommendations (in the GDPS/PPRC V3R13 Installation
> and Customization Guide) about System Logger, which, as seems usual with
> each GDPS release, have changed again.
>
> Now I read some confusing and/or contradicting information (Ch 2.6).
>
> * The recommendation remains to not run System Logger on GDPS
> K-systems. GDPS will kill it if found.
>
> * There is a new IXGCNFxx member with parameters for System Logger.
>
> * The GDPS manual recommends ("To prevent XCFAS on the Controlling
> systems from allocating the LOGR CDS") to specify MANAGE ALLOWACCESS(NO) in
> IXGCNFxx on GDPS K-systems.
>
> What is the use of the last recommendation?
>
> * IXGCNFxx is used by System Logger, which is not started there,
> so it will never be processed.
>
> * Why would XCFAS access the LOGR CDS if not directed so by System
> Logger?
>
> * If yet so, how would XCFAS know about the XCFCNFxx restriction?
>
> DISPLAY LOGGER,IXGCNF,MANAGE
> IXG602I DISPLAY LOGGER COMMAND NOT PROCESSED,
> THE SYSTEM LOGGER IS NOT ACTIVE.
>
> Am I missing something?
>
> Regards,
> Kees.
>
>
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
>
>
> --
> 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 information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to this
e-mail or attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately by return
e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission of
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered number
33014286
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL5 and ceedump
Yes, a deliberate area left specifically to catch any overflow and for no other purpose, similar to a patch-area. Technique arises before SSRANGE exists. If SSRANGE were subsequently used, it would/could catch the problem, but it is not as simple as the APAR text makes out (from memory of the text). So SSRANGE would "help" but not necessarily be sufficient, and remember that in cases the originally code is deliberately overflowing (to overcome an old compiler limitation). Then you get into "change that costs (development/testing/implementation) but achieves nothing, which is sometimes difficult (but important) to "sell" to management. Those who didn't buy (and who migrated early to V5+) reaped that whirlwind. Note that with V5+, the LE runtime option CHECK no longer influences anything. You can't deploy with SSRANGE(ON) and run with CHECK(OFF). Amusingly (to me anyway) people who run CHECK(ON) in Production complained about the additional "overhead" of the check for CHECK being ON or OFF. On Tue, 10 Jan 2017 04:10:12 -0600, Elardus Engelbrecht wrote: >Gibney, Dave wrote: > >>A frequent, even standard way to get past the size limit of a COBOL array, or >>more appropriately table, was to define more "empty" space after it. Since >>subscript bounds checking was always turned off for performance reasons, you >>could effectively address substantially larger than the size limit of any >>single 01 item. > >Hmmm, it reminds me of a sort of patch area? > >I'm curious, what about usage of SSRANGE compile option and CHECK(ON) runtime >option to avoid going over an array/table and getting an ABEND? Or will that >subscript bounds checking not help you here? > >I'm also puzzled by that APARs and the comments in this thread. (We're still >at COBOL v4, 5655-S71) > >Just following this thread out of curiousity. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: COBOL5 and ceedump
There is a conflation of two issues, with the first being in two parts. Issue 1) Part a) Can't define enough storage for a table due to COBOL limits. This is only an issue for "old" programs, where limits for table-size were imposed by the compiler. The "expedient" approach was to define consecutive tables, the subsequent ones being "catch-all" for overflow from the main table. More resilient approaches would have been available, but would have required "more thought". Issue 1) Part b) This table can never fill, so it doesn't matter that it is used in 20 sub-programs with no checking - it just logically can't fill Of course, for some given number of tables, it fills, and it does so at 02:30. Temporary expedient is to add an "overflow" table in the main program, and "fix it properly" some time later. Which only ever happens piecemeal, when one of the sub-programs has to change. Issue 2) the inexperienced programmer Previous to V5+, the indexes are (more) safely tucked-away in the TGT, out of immediate danger of being trashed. It was not impossible to trash, but less likely. With the V5+ change, a simple overrun using an index could trash the index, leading to a complex issue for an inexperienced programmer, even if a more experienced programmer may expend less effort identifying the issue (and, ideally, not having the issue in the first place). Prior to V5+, something else would be trashed, but the current value of the index would at least be pointing to the trashed value, rather than to somewhere wild (which may or may not have subsequently been trashed, and which may even be program code, or a system area, or whatever). Yes, absolutely, to never access storage outside the storage you've defined is the best thing to do, but when a new beginner does access something in error, it is less than hepful that something completely weird may happen (and remembering that the absolute worst situation is when something "happens", but it is not noticed/immediately connected to the problem. The frustrating thing was the up to V4.2 the "extending a table" method was covered in the Programming Guide, where OPT(FULL) was discussed (a warning to not remove innocent-looking "unused" tables that were used for this purpose). With FULL being replaced by a new option, the reference disappeared from the V5 documentation, but it cannot be argued that IBM (someone) was aware of the issue existing before it was idly changed. The reason for location was given as "performance", though I can't really visualise why an index "down there somewhere at the end of the table of length up to 999,999,999 bytes" can outperform an index "right here, immediately in front of the table" if the overwhelming need was to have the indexes defined, for the first time, intermingle with WORKING-STORAGE, user-defined, data. There's also indexes for LOCAL-STORAGE and, of course, without any possibility to locate with the table, the LINKAGE SECTION. I don't know for 100% where indexes (indices) are located, as I've not got access to V5+ nor seen a listing subsequent to the PTFs. They may or may not be in "as safe" a place as they were before, but I don't think they'll be moving again any time soon, as I think the change was substantial to apply the fix. As well as the COBOL Cafe discussion, there was a discussion on LinkedIn, which got comment from Tom Ross. In the end, the "fix" was unexpected from the results of those discussions. On Tue, 10 Jan 2017 11:27:34 +0100, Peter Hunkeler wrote: > >>A frequent, even standard way to get past the size limit of a COBOL array, or >>more appropriately table, was to define more "empty" space after it. Since >>subscript bounds checking was always turned off for performance reasons, you >>could effectively address substantially larger than the size limit of any >>single 01 item. > > > >I understand. I also read the head of the thread that Bill posted. > > > >It seems kind of ridiculous to me to justify all this with "less experienced >programmers". I remember when I was told how to program, I was told to >always make sure my coded does not go beyond the table. This is nothing >difficult to do. There is no excuse not to do it. > > >And as for the "standard way" to cheat the Cobol table restriction (I'm no >Cobol programmer, sorry): Cheating is cheating. Shudder But it explains at >least why IBM agreed to change the code. Thanks. > > > > >-- >Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Confusing info about System Logger and GDPS K-systems
These new function APARs may shed some light: OA50781 and OA50775
They talk about secondary controlling systems (KSYS) being present within
the SYSPLEX, and IPL order.
I hope this helps!
On Tue, Jan 10, 2017 at 5:24 AM, Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:
> Hello,
>
> We run GDPS V3R13 and z/OS V2.2.
> I am reading the GDPS recommendations (in the GDPS/PPRC V3R13 Installation
> and Customization Guide) about System Logger, which, as seems usual with
> each GDPS release, have changed again.
>
> Now I read some confusing and/or contradicting information (Ch 2.6).
>
> * The recommendation remains to not run System Logger on GDPS
> K-systems. GDPS will kill it if found.
>
> * There is a new IXGCNFxx member with parameters for System Logger.
>
> * The GDPS manual recommends ("To prevent XCFAS on the Controlling
> systems from allocating the LOGR CDS") to specify MANAGE ALLOWACCESS(NO) in
> IXGCNFxx on GDPS K-systems.
>
> What is the use of the last recommendation?
>
> * IXGCNFxx is used by System Logger, which is not started there,
> so it will never be processed.
>
> * Why would XCFAS access the LOGR CDS if not directed so by System
> Logger?
>
> * If yet so, how would XCFAS know about the XCFCNFxx restriction?
>
> DISPLAY LOGGER,IXGCNF,MANAGE
> IXG602I DISPLAY LOGGER COMMAND NOT PROCESSED,
> THE SYSTEM LOGGER IS NOT ACTIVE.
>
> Am I missing something?
>
> Regards,
> Kees.
>
>
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
>
>
> --
> 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: Confusing info about System Logger and GDPS K-systems
Hi Kees -
While I don't have an answer for your question, I do see a very similar
question posed to the "GDPS User Community" forum. Any GDPS questions I
have, I ask there.
You should be able to search for that community from here:
https://apps.na.collabserv.com/communities
It is restricted, so you would need to request access.
On Tue, Jan 10, 2017 at 5:24 AM, Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:
> Hello,
>
> We run GDPS V3R13 and z/OS V2.2.
> I am reading the GDPS recommendations (in the GDPS/PPRC V3R13 Installation
> and Customization Guide) about System Logger, which, as seems usual with
> each GDPS release, have changed again.
>
> Now I read some confusing and/or contradicting information (Ch 2.6).
>
> * The recommendation remains to not run System Logger on GDPS
> K-systems. GDPS will kill it if found.
>
> * There is a new IXGCNFxx member with parameters for System Logger.
>
> * The GDPS manual recommends ("To prevent XCFAS on the Controlling
> systems from allocating the LOGR CDS") to specify MANAGE ALLOWACCESS(NO) in
> IXGCNFxx on GDPS K-systems.
>
> What is the use of the last recommendation?
>
> * IXGCNFxx is used by System Logger, which is not started there,
> so it will never be processed.
>
> * Why would XCFAS access the LOGR CDS if not directed so by System
> Logger?
>
> * If yet so, how would XCFAS know about the XCFCNFxx restriction?
>
> DISPLAY LOGGER,IXGCNF,MANAGE
> IXG602I DISPLAY LOGGER COMMAND NOT PROCESSED,
> THE SYSTEM LOGGER IS NOT ACTIVE.
>
> Am I missing something?
>
> Regards,
> Kees.
>
>
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
>
>
> --
> 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
Confusing info about System Logger and GDPS K-systems
Hello,
We run GDPS V3R13 and z/OS V2.2.
I am reading the GDPS recommendations (in the GDPS/PPRC V3R13 Installation and
Customization Guide) about System Logger, which, as seems usual with each GDPS
release, have changed again.
Now I read some confusing and/or contradicting information (Ch 2.6).
* The recommendation remains to not run System Logger on GDPS
K-systems. GDPS will kill it if found.
* There is a new IXGCNFxx member with parameters for System Logger.
* The GDPS manual recommends ("To prevent XCFAS on the Controlling
systems from allocating the LOGR CDS") to specify MANAGE ALLOWACCESS(NO) in
IXGCNFxx on GDPS K-systems.
What is the use of the last recommendation?
* IXGCNFxx is used by System Logger, which is not started there, so it
will never be processed.
* Why would XCFAS access the LOGR CDS if not directed so by System
Logger?
* If yet so, how would XCFAS know about the XCFCNFxx restriction?
DISPLAY LOGGER,IXGCNF,MANAGE
IXG602I DISPLAY LOGGER COMMAND NOT PROCESSED,
THE SYSTEM LOGGER IS NOT ACTIVE.
Am I missing something?
Regards,
Kees.
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to this
e-mail or attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately by return
e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission of
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered number
33014286
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: KC: www-03.ibm.com vs. www.ibm.com
Paul Gilmartin wrote: >(Trying again; trying not to fumble the links this time.) That is all right. Only *after* I clicked, then I see this 'Make sure the web address http://http is correct.' Nasty habit of mine to click without looking! ;-) ... the same as putting your hand in a hole to see if there are any snakes are sitting there...[1] 8-O >o Is the -nn redirection used for load balancing which I thwart by bookmarking > it explicitly? Perhaps. I sometimes observed in the past that IBM pages starting with www-1, www-2, www-3, www, etc, all have different varying loading times. >o Or is www-03 stable so I should bookmark it? Do what zMan said, keep your bookmarks up to date. PITA, but the only way to survive... Groete / Greetings Elardus Engelbrecht [1] - Last month I had to use a broom to move small Mozambique spitting cobra (Naja mossambica) out of my home... https://en.wikipedia.org/wiki/Mozambique_spitting_cobra -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: COBOL5 and ceedump
>A frequent, even standard way to get past the size limit of a COBOL array, or >more appropriately table, was to define more "empty" space after it. Since >subscript bounds checking was always turned off for performance reasons, you >could effectively address substantially larger than the size limit of any >single 01 item. I understand. I also read the head of the thread that Bill posted. It seems kind of ridiculous to me to justify all this with "less experienced programmers". I remember when I was told how to program, I was told to always make sure my coded does not go beyond the table. This is nothing difficult to do. There is no excuse not to do it. And as for the "standard way" to cheat the Cobol table restriction (I'm no Cobol programmer, sorry): Cheating is cheating. Shudder But it explains at least why IBM agreed to change the code. Thanks. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL5 and ceedump
Gibney, Dave wrote: >A frequent, even standard way to get past the size limit of a COBOL array, or >more appropriately table, was to define more "empty" space after it. Since >subscript bounds checking was always turned off for performance reasons, you >could effectively address substantially larger than the size limit of any >single 01 item. Hmmm, it reminds me of a sort of patch area? I'm curious, what about usage of SSRANGE compile option and CHECK(ON) runtime option to avoid going over an array/table and getting an ABEND? Or will that subscript bounds checking not help you here? I'm also puzzled by that APARs and the comments in this thread. (We're still at COBOL v4, 5655-S71) Just following this thread out of curiousity. Groete / Greetings Elardus Engelbrecht Real programmers don't document their programs. If it was hard to write, it should be hard to understand. ;-) If a program is useless, it will have to be documented. There are 2 ways to write error-free programs; only the third one works. Those who can't write programs, write help files. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL5 and ceedump
A frequent, even standard way to get past the size limit of a COBOL array, or more appropriately table, was to define more "empty" space after it. Since subscript bounds checking was always turned off for performance reasons, you could effectively address substantially larger than the size limit of any single 01 item. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Peter Hunkeler > Sent: Monday, January 09, 2017 10:42 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: AW: Re: COBOL5 and ceedump > > > >For APAR PI65115, it looks like a separate APAR PI68274, was opened for > >Cobol 6.1 If you look at the information page for PI65115: > >https://urldefense.proofpoint.com/v2/url?u=http-3A__www- > 2D01.ibm.com_su > >pport_docview.wss-3Fuid- > 3Dswg1PI65115&d=DgIFAw&c=C3yme8gMkxg_ihJNXS06Zy > >Wk4EJm8LdrrvxQb- > Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=fMuLmQMzPx5DmslJNY_BCN > >Y0FVnGwzmPH7pETyG26Ys&s=UgfbkofOrtYfQsIO9ZMiM6G0M4fAyuman5V > LiwvHq3U&e= > > > Out of interest I had a look at what this is all about, and I must admit I'm > baffled. What does that solution help? More, I'm baffled the new behaviour > was accepted as an APARable problem. > > > Writing beyond the end of a table overwrites something, be that the index- > name or some other data. And it may lead to abnormal ends (the more lucky > case), or worst, wrong data to be processed without even recognizing this > fact. It is one of the most problematic coding error, IMHO. > > > So, the PTF will not fix anything in my opinion. It will revert to the > previous > way of how tables are handled by the compiler, yes, but that's it. > > > -- > Peter Hunkeler > > > > > -- > 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
