Getting the DFHEIENT macro to generate an RSECT (CICS/assembler)
I am trying to set the global conditional-assembly variable to 1 in order to get the DFHEIENT macro to generate an RSECT instead of a CSECT. But the translator gets in the way by automatically inserting a DFHEIGBL macro invocation just before the DFHEIENT macro, resetting to zero. How can I prevent the translator from doing this? Thanks, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ESTAE and IEBCOPY
In one of our REXX procedures we execute IEBCOPY to copy a member from one PDS to another. Sometimes IEBCOPY fails (e.g., for lack of space either in the directory or the library). It intercepts the abend through its ESTAE routine and returns a CC=8 with a text message to SYSPRINT. We would like to be able to receive more specific information as to the abend code and reason code of the IEBCOPY fail so we wrote a front-end which creates our own ESTAE before calling IEBCOPY so we can capture the information from the SDWA at abend time. But it appears that IEBCOPY overlays our ESTAE with its own so we don't get control. So we decided that when IEBCOPY returns to our front-end we would locate the RTM2WA and glean the information from it. But the pointer to the RTM2WA (TCBRTWA) is zero at that point (we suppose that IEBCOPY cancels its ESTAE before returning to us and the RTM2WA is released). Does anybody have any ideas how we might capture the abend and reason codes in spite of all this? Thanks, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RTM2WA
Where can I find the DSECT for the RTM2WA control block? I did not find it in either SYS1.MACLIB or SYS1.AMODGEN. Thanks, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Communication between two computer systems (LPARS or physical)
Thank you all for your informative answers! Steff On Thu, 12 Aug 2021 at 12:19, Timothy Sipples wrote: > Lennie Dymoke-Bradshaw wrote: > >Looking through the various answers here, I note that someone has > >mentioned the need for some kind of security, so that others cannot > >trigger actions they are not supposed to. > >I think those security issues conflict with your requirement to run > >synchronisation without any authorisation. > > I don't think that's a given. As long as the participants in this > synchronization network can establish and maintain trust with one another, > that should be fine even if none of them are particularly trusted by > anything else outside their circle. Metaphorically it's like a secret > society. DLTs (Blockchain networks) generally operate this way, for > example. (I'm not necessarily suggesting a DLT-based approach in this > case.) > > Have we learned yet whether or not it's acceptable if this synchronization > network provides different answers if you ask different nodes the same > question at exactly the same time? For example, if you have a 3 node > network then hypothetically you could ask a question and if a majority of > the nodes (2 out of 3) agree on a common answer, that's a valid answer. As > another example, if the "truth" is 5 minutes out of date, that's OK, and a > node will take some action if it isn't able to check in with its peers and > maintain truth-consensus within 5 minute intervals. > > There are a LOT of possible options. > > - - - - - - - - - - > Timothy Sipples > I.T. Architect Executive > Digital Asset & Other Industry Solutions > IBM Z & LinuxONE > - - - - - - - - - - > E-Mail: sipp...@sg.ibm.com > > -- > 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
Communication between two computer systems (LPARS or physical)
We have global data pointed to by a name-token that is available to all the address spaces in each computer system. We want to make sure that any updates to the data in one system are broadcast to the other computer systems in the installation (LPARs or physical computers). Or at the very least notify the other systems that their data is not up-to-date. What would be the simplest and cheapest way to send some kind of signal from one system to the other without requiring I/O to shared DASD? We thought of issuing a console command starting a started task in each of the other computer systems (the JES2 spool is shared by all the systems.) . But this is problematic since the required SVC (34) requires that the program be authorized. Any other ideas? Thanks, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Locating LE's CIB in CICS
Greetings, I would like to be able to locate, under CICS, the CIB representing the original abend (ideally in the XPCTA GLUE exit) before LE intercepted it and substituted its own 4038 user abend. Not surprisingly, the CEE3CIB callable routine abends on S0C4. Anybody know how to do this? All the best, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Finding the NETNAME within TSO
How can I discover the netname of a TSO user from within TSO? Either directly in REXX or via a called assembler subroutine? Thanks, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VSAM write error: file status key = 24
Greetings, After REPRO-ing a VSAM KSDS file defined with shareoptions (4,3) to a file defined with shareoptions (4,4), we started receiving the following error on a write attempt (COBOL program): Status key=24 Meaning: An attempt was made to write beyond the externally defined boundaries of a relative or indexed file. The (4,4) file is identical to the (4,3) file in all respects except for the shareoptions. The error never occurs for the (4,3) file and occurs intermittently for the (4,4) file. Can anyone suggest what the problem might be? Thanks, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Isolating a CSECT within a load module
Thank you Greg, Paul and Max for your informative replies!
On Tue, 5 Jan 2021 at 15:12, Massimo Biancucci wrote:
> I tried to develop you hints:
>
> // EXPORT SYMLIST=*
> // SET INPMOD=oldmd
> // SET OUTMOD=newmod
> // SET INPLIB=myold.lib
> // SET OUTLIB=mynew.lib
> // SET AMBDSN=AMBLIST3
> // SET DSP='MOD,PASS' DSP='MOD,CATLG'
> //*---*
> //* *
> //*---*
> //ST010 EXEC PGM=AMBLIST
> //SYSPRINT DD DSN=,DISP=(),
> // SPACE=(TRK,(5,5),RLSE)
> //LOADLIB DD DISP=SHR,DSN=
> //SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> LISTIDR DDN=LOADLIB,MEMBER=
> /*
> //*---*
> //* *
> //*---*
> //ST020 EXEC PGM=SORT
> //SYSOUT DD SYSOUT=*
> //SORTIN DD DSN=,DISP=SHR
> //SORTOUT DD DSN=,DISP=(),
> // SPACE=(TRK,(5,5),RLSE),DCB=(LRECL=80,RECFM=FB,DSORG=PS)
> //SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> SORT FIELDS=COPY
> OUTFIL FNAMES=SORTOUT,REMOVECC,
> INCLUDE=(2,10,CH,EQ,C'CSECT:',AND,
>12,8,CH,NE,C''),
> OUTREC=(C' REPLACE ',12,8,80:X),
> TRAILER1=(' INCLUDE SYSLIB()',/,
>' NAME (R)')
> /*
> //*---*
> //* *
> //*---*
> //ST030EXEC PGM=HEWL,
> // PARM='LET,XREF,MAP,LIST,NCAL'
> //SYSPRINT DD SYSOUT=*
> //SYSUT1 DD DSN=&,SPACE=(1024,(120,120),,,ROUND),
> // DCB=BUFNO=1
> //*YSLIN DD DISP=SHR,DSN=J48017.OSET.LOAD(IRXINIT)
> //SYSLIB DD DISP=SHR,DSN=
> //SYSLMOD DD DISP=SHR,DSN=()
> //SYSLIN DD DISP=SHR,DSN=
> //*---*
> //* *
> //*---*
> //ST040 EXEC PGM=AMBLIST
> //SYSPRINT DD SYSOUT=*
> //LOADLIB DD DISP=SHR,DSN=
> //SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> LISTIDR DDN=LOADLIB,MEMBER=
> LISTLOAD DDN=LOADLIB,MEMBER=
> /*
>
> and it seems it's still working.
> I'm sure it's possible to further optimize, anyway I think it's a kind of
> tool you use not so often.
> Anyway take the two of them as POC.
>
> Best regards.
> Max
>
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> Mail
> priva di virus. www.avast.com
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Il giorno lun 4 gen 2021 alle ore 18:44 Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> ha scritto:
>
> > On Mon, 4 Jan 2021 16:32:47 +0100, Massimo Biancucci wrote:
> > >
> > >I've tried to use sort to help.
> > >
> > >// EXPORT SYMLIST=*
> > >// SET INPMOD=oldmd
> > >// SET OUTMOD=newmod
> > >// SET INPLIB=myold.lib
> > >// SET OUTLIB=mynew.lib
> > >
> > I like that sort of parameterizing. It puts the variables up front,
> > viewable at a glance. I'd add the AMBLIST2 DSNs to the SET list.
> >
> > Can something such as "SET DISP={PASS|CATLG} be used to control
> > temp vs. permanent workfiles?
> >
> > >//* *
> > >//*---*
> > >//ST010 EXEC PGM=IDCAMS
> > >//SYSPRINT DD SYSOUT=*
> > >//SYSIN DD *,SYMBOLS=(JCLONLY,SYMBLOG)
> > > DELETE
> > > IF MAXCC=8 THEN SET MAXCC=0
> > >/*
> > >//*---*
> > >//* *
> > >//*---*
> > >//ST020 EXEC PGM=AMBLIST
> > >//SYSPRINT DD DSN=,DISP=(,CATLG),
> > >// SPACE=(TRK,(5,5),RLSE)
> > >//LOADLIB DD DISP=SHR,DSN=
> > >//SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> > > LISTIDR DDN=LOADLIB,MEMBER=
> > >/*...
> > My very peculiar preference is to omit the IDCAMS steps and code either:
> > //HANDLE DD DSN=,DISP=(MOD,CATLG),
> > // SPACE=(TRK,(5,5),RLSE)
> > //SYSPRINT DD DISP=OLD,DSN=*.HANDLE,VOL=REF=*.HANDLE
> >
> > Or:
> > //HANDLE DD DSN=,DISP=(MOD,DELETE),
> > // SPACE=(TRK,(5,5),RLSE)
> > //SYSPRINT DD DSN=,DISP=(MOD,CATLG),
> > // SPACE=(TRK,(5,5),RLSE)
> >
> > But, performance? Is a failing IDCAMS step less overhead than
> > an otiose DISP=(MOD,DELETE) etc.?
> >
> > >I used "no-temp" dataset to better help in understanding the process.
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access
Re: VSAM file discrepancies
The duplication exists in the data, not in the index. On Tue, 19 Jan 2021 at 18:22, Cameron Conacher wrote: > A KSDS with duplicate full primary key values? > Are you sure? > > Sent from my iPhone > > > On Jan 19, 2021, at 10:19 AM, Steff Gladstone > wrote: > > > > Greetings, > > > > We are trying to figure out how a VSAM file became compromised. That is, > > even though the primary key is unique, when we do a REPRO, we see that > the > > data contains an extra record with the same key. > > > > The file is updated from two different computers via a batch COBOL > program. > > The share options are (4,3) and an enqueue (with parameter SYSTEMS) is > > performed (using an assembler subroutine) before any update is done. The > > site has a 3rd-party product from CA that propagates the ENQ from one > > computer to the other. We even tested the ENQ and saw that an update > from > > the second computer was blocked when the first computer previously issued > > an ENQ prior to its update. > > > > It looks as if an update in one computer has not been committed from > memory > > to disk before the update in the second computer occurs. Which > definitions > > are lacking that would prevent this from happening? > > > > Thanks in advance, > > Steff Gladstone > > > > -- > > 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
VSAM file discrepancies
Greetings, We are trying to figure out how a VSAM file became compromised. That is, even though the primary key is unique, when we do a REPRO, we see that the data contains an extra record with the same key. The file is updated from two different computers via a batch COBOL program. The share options are (4,3) and an enqueue (with parameter SYSTEMS) is performed (using an assembler subroutine) before any update is done. The site has a 3rd-party product from CA that propagates the ENQ from one computer to the other. We even tested the ENQ and saw that an update from the second computer was blocked when the first computer previously issued an ENQ prior to its update. It looks as if an update in one computer has not been committed from memory to disk before the update in the second computer occurs. Which definitions are lacking that would prevent this from happening? Thanks in advance, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Isolating a CSECT within a load module
Greetings, Can anyone suggest a method of isolating or extracting a CSECT (statically-linked called program) from a load module? The only (clumsy) method I can think of is using (within the linkage editor or binder) a REPLACE statement ahead of an INCLUDE statement and specifying in the REPLACE all of the other CSECTS in the load module. For example, if the load module is called LOADMOD1 and contains CSECTS A,B,C,D,E,F,G,H and I want to isolate CSECT F, I would code: REPLACE A,B,C,D,E,G,H INCLUDE SYSLIB(LOADMOD1) NAME F(R) Obviously this is unwieldy for a load module with lots of CSECTs. Does anyone have a more elegant way of doing this? Thanks, Steff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Calculating duration from subtracting TOD clocks
Thank you! On Thu, 26 Nov 2020 at 23:32, Charles Mills wrote: > I should add that I have code that does exactly what you are talking > about. That's why I am familiar with the problem. > > // Keep track of time in [particular function] > Platform::STCKF(); > > // call [a particular function here] > > // Keep track of time in [particular function] > Platform::STCKF(); > timeInFunction += (TOD - EntryTOD); > > Platform::STCKF() is an inline call to __stckf() which is a hardware STCKF. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Charles Mills > Sent: Thursday, November 26, 2020 1:16 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Calculating duration from subtracting TOD clocks > > @Steff, I totally "get" your question. You have some function that is > called repeatedly and you want to know the total elapsed time spent in that > function. So you want to get a TOD on the way in, subtract it from a TOD on > the way out, and then sum those differences. Makes perfect sense. And you > are worried that you are factoring in 12 irrelevant bits that may add up > over time. > > You are (mostly) mathematically correct but if it were me I would not > worry about it. First of all, I suspect that in modern machines the actual > clock resolution is a lot finer than 1 usecond, so not all of those 12 bits > are irrelevant. Second, I suspect much of the error would cancel itself > out. But yes, I don't really know, and worst case, you could be off by > almost a usecond on every difference, and after a few thousand sums it > might amount to something. > > What to do? Well, you could just AND off those 12 bits. Little harm, > although on a box with finer resolution you are throwing away information > that might be relevant. How about just using STCKF; it has two benefits: > first, as the name implies, it is FASTER than an STCK in certain > circumstances -- much faster (the exact circumstances are irrelevant to > this discussion, but trust me, it is a LOT faster sometimes). And second, > the PoOp says "For STORE CLOCK FAST, when the value of a running clock is > stored, bits to the right of the rightmost bit that is incremented are > stored as zeros." > > QED > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Steff Gladstone > Sent: Thursday, November 26, 2020 7:08 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Calculating duration from subtracting TOD clocks > > Could someone answer 4gb's 11-year-late question? > > On Tuesday, April 17, 2018 at 11:53:30 PM UTC+3, 4gb...@gmail.com wrote: > > > On Monday, September 3, 2007 at 4:38:21 PM UTC-7, Ludmila Koganer wrote: > > > Hi, > > > I need to subtract two TOD times to find elapsed time. Currently I > convert > > > the two TOD times with STCKCONV and determine the elaped time > individually, > > > and then compute the difference. This works. However I thought I could > > > optimize the conversion, a little bit and I was wondering why not > subtract the > > > two TOD times to begin with. > > > > > > As I understand TOD time is the number of mic seconds elapsed since > midnight > > > of 1900-01-01. So when I subtract one TOD value from another the > duration > > > must be in micro seconds. > > > I'm 11 years late. Shouldn't you clear the low order 12 bits of each TOD > value before adding or subtracting them? Those low order bits are not > fractions of a microsecond, so including them in the math can produce up to > a micro second error. If you add a series of TOD values without clearing > the low bits that can add up to real money. > > -- > 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
Calculating duration by subtracting TOD clocks
Could someone answer 4gb's question? On Tuesday, April 17, 2018 at 11:53:30 PM UTC+3, 4gb...@gmail.com wrote: > Shouldn't you clear the low order 12 bits of each TOD value before adding or subtracting them? Those low order bits are not fractions of a microsecond, so including them in the math can produce up to a micro second error. If you add a series of TOD values without clearing the low bits that can add up to real money. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Calculating duration from subtracting TOD clocks
Could someone answer 4gb's 11-year-late question? On Tuesday, April 17, 2018 at 11:53:30 PM UTC+3, 4gb...@gmail.com wrote: > On Monday, September 3, 2007 at 4:38:21 PM UTC-7, Ludmila Koganer wrote: > > Hi, > > I need to subtract two TOD times to find elapsed time. Currently I convert > > the two TOD times with STCKCONV and determine the elaped time individually, > > and then compute the difference. This works. However I thought I could > > optimize the conversion, a little bit and I was wondering why not subtract the > > two TOD times to begin with. > > > > As I understand TOD time is the number of mic seconds elapsed since midnight > > of 1900-01-01. So when I subtract one TOD value from another the duration > > must be in micro seconds. > I'm 11 years late. Shouldn't you clear the low order 12 bits of each TOD value before adding or subtracting them? Those low order bits are not fractions of a microsecond, so including them in the math can produce up to a micro second error. If you add a series of TOD values without clearing the low bits that can add up to real money. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Using STCKCONV in a CICS GLUE
We need to capture the date and time in a GLUE and need more precision than the CICS variables give us. Can we use the STCKCONV macro in a GLUE? Could it cause all of CICS to enter a wait? Or is it essentially pure CPU? Thanks, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Tracking called (non-main) programs using SMF records
We would like to clean up our load libraries by deleting unused programs. Is there any way to use SMF data to track real-time usage of programs which are not main programs but are called by other programs? We were under the impression that only executions of main programs (PGM=) were recorded with SMF. Scanning program sources for called programs is unsatisfactory for us since the call could be dynamic (name of program contained in a variable) or conditional on a particular set of circumstances that never occurs in practice. Thanks in advance! Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF: Limiting update-authorization of a file to a particular application
But if I TSOEXEC CALL the Cobol I/O routine, will it retain the context between calls? Won't the DCBs and ACBs and working storage be reinitialized on every call? בתאריך יום ה׳, 7 במרץ 2019, 02:34, מאת Walt Farrell : > On Wed, 6 Mar 2019 19:29:05 +0200, Steff Gladstone < > steff.gladst...@gmail.com> wrote: > > >One further question: > > > >Would use of IKJEFTSI/IKJEFTSR/IKJEFTST work here? I.e., provide an > >isolated eenvironment for RACF while maintaining continuity within the I/O > >routine without re-initializing its working storage on each call? > > No. Your only good approach for doing this under TSO/E, if you're having > problems with a dirty environment, is to TSOEXEC CALL your COBOL program, > and have it run entirely isolated in the parallel TMP. You will, though, > still need to make sure you have a properly constructed PROGRAM ** profile > to ensure that the parallel TMP stays clean. > > Of course, a multiple address space environment, perhaps one created using > the UNIX System Services fork() operation could also work. That's one > variation of the approach that Shmuel suggested. > > -- > Walt > > -- > 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: RACF: Limiting update-authorization of a file to a particular application
One further question: Would use of IKJEFTSI/IKJEFTSR/IKJEFTST work here? I.e., provide an isolated eenvironment for RACF while maintaining continuity within the I/O routine without re-initializing its working storage on each call? On Wed, 6 Mar 2019 at 19:01, Steff Gladstone wrote: > Although we have progressed with creating an program-controlled > environment, we are still experiencing problems in this area. > > We have a COBOL routine whose purpose is to open a VSAM data set on the > first call, perform I/O (read and write) on subsequent calls, and finally > close the dataset on the final call. We want to force most users to update > the VSAM dataset only via this COBOL program, allowing only privileged > users (= system programmers) the option of updating the dataset using other > programs or utilities. For this reason we opted to implement RACF > program-control, as per Shmuel Metz's suggestion. > > The COBOL I/O routine is called by a fairly complex TSO/ISPF application. > So we decided to communicate to the I/O routine via a subtask in order to > simplify the environment (as per Walt Farrell's claim that a new TCB > creates a parallel isolated environment for RACF). > > First we tried implementing it the "stupid" way, with COBOL calling REXX > calling the COBOL I/O routine (via TSOEXEC, CALL, or LINKPGM - it didn't > matter). We expected the call to REXX to create a new subtask. The RACF > program control in fact worked well in this scenario, but (as expected) the > COBOL I/O routine (with its working storage and DCB's) is reinitialized on > each call and so we have to re-OPEN on each call and there is no continuity > between read and write calls. > > Then we did the following: we wrote an LE-enabled assembler routine that > attaches a subtask (also LE-enabled) on the first call. The subtask loads > the COBOL I/O routine then waits for work. On every subsequent call to the > assembler routine the subtask is posted and it calls the COBOL I/O routine > and returns the results to the assembler routine and re-enters a wait till > the next call. And so on, until the final call when the subtask terminates > and is detached. > > This works ok for privileged users (i.e., the subtasking and I/O logic > works fine, the COBOL I/O routine is not reintiaiized on each call, and of > course there are no RACF issues). But for non-privileged users RACF issues > the following error message just after the COBOL I/O routine is called by > the subtask:: > > ICH418I CONDITIONAL ACCESS LIST FOR DATA SET output.dataset DID NOT GRANT > AUTHORITY TO PROGRAM(S): EXEC CALL EXEC CALL > > This despite the fact that the COBOL I/O routine is executing under a > separate subtask. > > Can anyone help us out here? > > Thanks in advance, > Steff Gladstone > > > > > On Thu, 21 Feb 2019 at 23:33, Walt Farrell wrote: > >> On Thu, 21 Feb 2019 15:22:33 +, Seymour J Metz >> wrote: >> >> >AFAIK it won't reset the dirty bit. It does isolate AC(0) from AC(1). >> >> Yes, it will, for that isolated parallel environment. >> >> -- >> Walt >> >> -- >> 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: RACF: Limiting update-authorization of a file to a particular application
Although we have progressed with creating an program-controlled environment, we are still experiencing problems in this area. We have a COBOL routine whose purpose is to open a VSAM data set on the first call, perform I/O (read and write) on subsequent calls, and finally close the dataset on the final call. We want to force most users to update the VSAM dataset only via this COBOL program, allowing only privileged users (= system programmers) the option of updating the dataset using other programs or utilities. For this reason we opted to implement RACF program-control, as per Shmuel Metz's suggestion. The COBOL I/O routine is called by a fairly complex TSO/ISPF application. So we decided to communicate to the I/O routine via a subtask in order to simplify the environment (as per Walt Farrell's claim that a new TCB creates a parallel isolated environment for RACF). First we tried implementing it the "stupid" way, with COBOL calling REXX calling the COBOL I/O routine (via TSOEXEC, CALL, or LINKPGM - it didn't matter). We expected the call to REXX to create a new subtask. The RACF program control in fact worked well in this scenario, but (as expected) the COBOL I/O routine (with its working storage and DCB's) is reinitialized on each call and so we have to re-OPEN on each call and there is no continuity between read and write calls. Then we did the following: we wrote an LE-enabled assembler routine that attaches a subtask (also LE-enabled) on the first call. The subtask loads the COBOL I/O routine then waits for work. On every subsequent call to the assembler routine the subtask is posted and it calls the COBOL I/O routine and returns the results to the assembler routine and re-enters a wait till the next call. And so on, until the final call when the subtask terminates and is detached. This works ok for privileged users (i.e., the subtasking and I/O logic works fine, the COBOL I/O routine is not reintiaiized on each call, and of course there are no RACF issues). But for non-privileged users RACF issues the following error message just after the COBOL I/O routine is called by the subtask:: ICH418I CONDITIONAL ACCESS LIST FOR DATA SET output.dataset DID NOT GRANT AUTHORITY TO PROGRAM(S): EXEC CALL EXEC CALL This despite the fact that the COBOL I/O routine is executing under a separate subtask. Can anyone help us out here? Thanks in advance, Steff Gladstone On Thu, 21 Feb 2019 at 23:33, Walt Farrell wrote: > On Thu, 21 Feb 2019 15:22:33 +, Seymour J Metz wrote: > > >AFAIK it won't reset the dirty bit. It does isolate AC(0) from AC(1). > > Yes, it will, for that isolated parallel environment. > > -- > Walt > > -- > 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: RACF: Limiting update-authorization of a file to a particular application
Do I understand correctly that TSOEXEC CALL creates a new subtask environment which is "insulated" from the goings-on in the mother task? Would specifying TASKLIB further ensure that only those modules loaded/linked/attached from the TASKLIB library need be RACF-authorized? Or is there something I am missing? On Mon, 18 Feb 2019 at 16:48, Walt Farrell wrote: > On Sun, 17 Feb 2019 18:05:59 +0200, Steff Gladstone < > steff.gladst...@gmail.com> wrote: > > >Ok. We have been playing around with program control.If PROG1 (a COBOL > >program incidentally) is to be allowed exclusively to update file MY.FILE, > >then we: > > > >1. introduced PROG1 into the list of programs in AUTHPGM in member > IKJEFT00 > > Unless the program is linkedited with AC(1) and needs to run authorized > (most COBOL programs don't) I don't see a reason to put it in AUTHPGM. > > You will likely run into problems in a TSO environment with the > environment being marked dirty, as you noted. > > Your best hope to avoid that is to make sure you've followed the > instructions in the RACF Security Administrators Guide about defining the > PROGRAM ** profie and all the libraries that you should specify for its > ADDMEM operand. Make sure you use the specified UACC value, too. > > If that doesn't work, then your next approach would be to try TSOEXEC CALL > ... to invoke the program. > > Really, all of this is explained in the Security Administrators Guide in > the sections on Program Control and Program Access to Data (PADS), along > with some examples and recommendations. As getting this working under TSO > is very difficult, my best recommendation is to read those sections and > follow the instructions exactly. > > -- > Walt > > -- > 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: RACF: Limiting update-authorization of a file to a particular application
Ok. We have been playing around with program control.If PROG1 (a COBOL program incidentally) is to be allowed exclusively to update file MY.FILE, then we: 1. introduced PROG1 into the list of programs in AUTHPGM in member IKJEFT00 2. Executed command RDEFINE for the file (and additionally for the LE runtime libraries - not sure if necessary) and PERMIT 'MY.FILE' WHEN(PROGRAM(PROG1)). The results were: 1. Executing PGM=PROG1 in batch -> good results 2. Executing a REXX procedure under PGM=IKJEFT01 in batch -> good results (when invoked either by CALL 'lib(PROG1)' or SELECT PGM(PROG1) 3. Executing a REXX procedure in TSO foreground invoking program with CALL 'lib(PROG1)' -> receives the following error: ISPS118L Service not invoked. A valid ISPF environment does not exist. 4. Executing a REXX procedure in TSO foreground invoking program with SELECT PGM(PROG1) -> receives the following error: IKJEFTSR interface error Authorized program 'PROG1'. Return code=20 Reason code=40. Current dialog statement: SELECT PGM(PROG1) We gather that we are running into the "dirty bit" problem that has been documented in various forums. What can we do to get around this (we need the program control feature under TSO foreground as well)? Thanks in advance, Steff Gladstone On Thu, 7 Feb 2019 at 18:06, Seymour J Metz wrote: > Program control, but pay close attention to the restrictions. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Steff Gladstone > Sent: Thursday, February 7, 2019 6:37 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: RACF: Limiting update-authorization of a file to a particular > application > > Greetings, > > > > We have an TSO application for end-users that allows them to update certain > VSAM and PDS files. In order for them to update these files we of course > have to give their users update-authorization under RACF for those files. > > > > We want to limit their ability to update the files only via the particular > TSO application (or via a particular I/O routine used by the application) > and not via any other application program or IBM utility (e.g., IEBCOPY, > ISPF on-line edit or utilities, etc.). > > > > How can we define the RACF authorizations in such a way as to limit the > end-users' update capabilities to the application (or to a particular I/O > routine) alone? Would the same (or similar) definitions work for a site > using Top Secret instead of RACF? > > > > Thank you in advance, > Steff Gladstone > > -- > 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
RACF: Limiting update-authorization of a file to a particular application
Greetings, We have an TSO application for end-users that allows them to update certain VSAM and PDS files. In order for them to update these files we of course have to give their users update-authorization under RACF for those files. We want to limit their ability to update the files only via the particular TSO application (or via a particular I/O routine used by the application) and not via any other application program or IBM utility (e.g., IEBCOPY, ISPF on-line edit or utilities, etc.). How can we define the RACF authorizations in such a way as to limit the end-users' update capabilities to the application (or to a particular I/O routine) alone? Would the same (or similar) definitions work for a site using Top Secret instead of RACF? Thank you in advance, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for an appropriate system exit
Thank you one and all for your excellent advice. בתאריך יום ב׳, 26 בנוב׳ 2018, 21:36, מאת Seymour J Metz : > The only documented way that I know of is with WTO; why the FM specifies > ROUTCDE=14 rather than 11 I don't understand. There's an undocumented ACB > interface. but I don't recall the setup details. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Jesse 1 Robinson > Sent: Saturday, November 24, 2018 3:17 PM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: Looking for an appropriate system exit > > Our SMF exits still use IEFYS to write messages to the job output stream. > If there were some other 'more modern' method, I'd use it, but I know of > none. As for doc, I've never found any. I just call the interface--which at > least seems to be a supported if somewhat clandestine UI--and it continues > to work through decades of OS upgrades. We absolutely need to write > messages from SMF exits. If not IEFYS, then how? I'm open to improvements. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Seymour J Metz > Sent: Saturday, November 24, 2018 11:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Looking for an appropriate system exit > > 1. IEFYS is a really old interface; I didn't think anybody was still > using it. The best place to look is probably the OS/360 documentation at > http://secure-web.cisco.com/1gnfRXs1KF_kQF-919fF6eZq16WYo4NjFG740q0HSIRf0e9hVyYm15nERpwmkSe9X4fUeZoKpEARI5iYlW8dBl3bhnlO7EiAfnMus7A7SPR9NMKQHFGwWU-G0uq78_vsmn4nB7dkqrtT5l_vwTQIm2L_K3jzxXHxQgmUE11hH5U8bQcV7Veylge_htj1Vdg4_8aDfe6tyRADVG2d8GFRYeen8ZACtgoTzdX0f8GMdgLTd37-jNBBHdaztHyYeEXt0d7e0PUEE3-Pc0QG0eLRKcMTXO2FXtzQCLl6SYrwNTBUese1rAqBXfr9AFTAUvuZ4zaruqj_ypr5tLg21PeWWDuDDKL496PQNaBelfn34ndBmfNJBmT2rIac1YuttyCG8ffJTQZ7l4KE3aMXs5MPezu5VMNb_Qu6v40jGFwHohkFPcjmA15EjM1OIaCXVwAZR/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F360%2Fos%2FR20.1_Mar71%2FGC28-6550-9_OS_System_Programmers_Guide_Rel_20.1_Jun71.pdf > > 2. Doesn't IEFACTRT run under the Initiator TCB? I would expect the > storage of the terminating job step to be long gone. > > 3. Show your parameter list and return code. You're running under the > Initiator, so it may be an issue with your security environment. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Steff Gladstone > Sent: Thursday, November 22, 2018 3:53 PM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: Looking for an appropriate system exit > > Three questions regarding IEFACTRT: > > 1. Where is use of IEFYS for writing messages to the JOBLOG documented? > The example given in the documentation for IEFACTRT is incomplete. Google > doesn't seem to locate the doc as well. > > 2. I am abending on S0C4 because getmained areas are automatically being > freed at end of step, before IEFACTRT gets control. It is not clear to me > if SUBPOOL alone can solve the problem. Do I need to specify > TCBADDR=TCBJSTCB on the STORAGE macro so that the "input TCB" is the > job-step TCB? What course is recommended? > > 3. The documentation says one can dynamically allocate within IEFACTRT but > the BPXWDYN routine returns a non-zero return code. (Same code that works > fine in a regular program.) Is this a limitation of BPXWDYN? Should I code > an SVC 99 call myself? > > Thank you in advance, > Steff Gladstone > > > > On Fri, 5 Oct 2018 at 16:17, Charles Mills wrote: > > > I use the CSVDYNEX interface extensively and it has been nothing but > > bulletproof in all of my experience. Kudos! > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Elardus Engelbrecht > > Sent: Friday, October 5, 2018 6:20 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Looking for an appropriate system exit > > > > Peter Relson wrote: > > > > >When the facility was developed, we took a stab at which existing > > >exits > > that we thought were most likely to be of help to the most customers. > > And I'd hope that new exits use it. > > > > That was one of the best stabs I got from Big Blue. It saved me an > > unneeded IPL when one of my SMF ex
Re: Looking for an appropriate system exit
Three questions regarding IEFACTRT: 1. Where is use of IEFYS for writing messages to the JOBLOG documented? The example given in the documentation for IEFACTRT is incomplete. Google doesn't seem to locate the doc as well. 2. I am abending on S0C4 because getmained areas are automatically being freed at end of step, before IEFACTRT gets control. It is not clear to me if SUBPOOL alone can solve the problem. Do I need to specify TCBADDR=TCBJSTCB on the STORAGE macro so that the "input TCB" is the job-step TCB? What course is recommended? 3. The documentation says one can dynamically allocate within IEFACTRT but the BPXWDYN routine returns a non-zero return code. (Same code that works fine in a regular program.) Is this a limitation of BPXWDYN? Should I code an SVC 99 call myself? Thank you in advance, Steff Gladstone On Fri, 5 Oct 2018 at 16:17, Charles Mills wrote: > I use the CSVDYNEX interface extensively and it has been nothing but > bulletproof in all of my experience. Kudos! > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Elardus Engelbrecht > Sent: Friday, October 5, 2018 6:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Looking for an appropriate system exit > > Peter Relson wrote: > > >When the facility was developed, we took a stab at which existing exits > that we thought were most likely to be of help to the most customers. And > I'd hope that new exits use it. > > That was one of the best stabs I got from Big Blue. It saved me an > unneeded IPL when one of my SMF exits went down the bit bucket. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for an appropriate system exit
After a respite of several months this topic has gotten hot again for us. We believe that using the IEFUSI and IEFACTRT exits answer our need to gain control at job-step initialization and again at job-step termination. My question is: if we use the dynamic exits facility, that is, the console command SETPROG EXIT,ADD,EX=,MOD=,LAST (or issue the equivalent CSVDYNEX macro in an assembler program) to add our exit routines to the system exit points SYS.IEFUSI AND SYS.IEFACTRT, and assuming we are careful to return R15=0 in our exit routines and not change anything in the passed parameters, could that still affect or override in any way the results of the default or system exit routines already in effect for those exit points? We would like our exits to be as innocuous as possible and not adversely affect what is already in the system. On 8 December 2017 at 15:47, Binyamin Dissen wrote: > > Your best/easiest would be a SAF exit for checking PROGRAM class - that > gets > control for each load without hooking stuff. Otherwise you can hook the > standard LOAD/LINK/ATTACH SVCs. The IEFUSI would have the EXEC PGM= name. > > On Wed, 6 Dec 2017 12:14:45 +0200 Steff Gladstone < > steff.gladst...@gmail.com> > wrote: > > :>Hi Binyamin, > :> > :>The application load libraries are full of obsolete code. We are trying > to > :>identify which programs are still active in the installation in order to > :>weed out obsolete legacy programs and clean up our load libraries, and > :>eventually, source libraries. > :> > :>We were hoping to choose an optimal exit that would enable us to capture > :>pertinent info: called load module name, load library name, caller name, > :>etc. We would prefer an exit that allows the designation of a number of > :>individual exit routines per exit (JES2 and CICS and, to a limited > extent, > :>DFSMS, provide this capability; I am not aware of other possibilities), > so > :>that we could easily disable or remove our code when necessary without > :>affecting other customized user code in that exit. > :> > :>Thanks for any assistance you can extend to us. > :> > :>Steff Gladstone > :> > :>On Wed, Dec 6, 2017 at 10:53 AM, Binyamin Dissen < > bdis...@dissensoftware.com > :>> wrote: > :> > :>> Can you give an example or two? > :>> > :>> On Wed, 6 Dec 2017 09:13:47 +0200 Steff Gladstone < > :>> steff.gladst...@gmail.com> > :>> wrote: > :>> > :>> :>In our installation we would like to implement certain checks and > :>> document > :>> :>certain run-time characteristics at the beginning and during program > :>> :>initialization and duration (chiefly Cobol programs). We would like > to > :>> :>implement this in a manner transparent to the application, without > :>> :>requiring the programmer to add lines of JCL or calls to subroutines > (we > :>> :>have thousands of legacy programs and jobs and don't want to have to > go > :>> :>through a massive conversion project). > :>> > :>> :>We are looking at initialization routines like CEEBINT. Can anyone > :>> :>recommend any other system exits that could be candidates for this > sort > :>> of > :>> :>thing. Any potential pitfalls we should be aware of? > :>> > :>> -- > :>> Binyamin Dissen > :>> http://www.dissensoftware.com > :>> > :>> Director, Dissen Software, Bar & Grill - Israel > :>> > :>> > :>> Should you use the mailblocks package and expect a response from me, > :>> you should preauthorize the dissensoftware.com domain. > :>> > :>> I very rarely bother responding to challenge/response systems, > :>> especially those from irresponsible companies. > :>> > :>> -- > :>> For IBM-MAIN subscribe / signoff / archive access instructions, > :>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > :>> > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TCBFSA field in the TCB DSECT
Or you could check if R14 is pointing to a SVC 3 instruction. Actually the routine (not written by me) was using the FSA to retrieve the pointer to the value of the PARM= parameter (saved R1). Presumably that's a valid use as well. It would make sense if the FSA is always below the line. Although theoretically the system could check the AMODE of the first program and allocate the SA accordingly. On 13 February 2018 at 13:02, Bernd Oppolzer <bernd.oppol...@t-online.de> wrote: > Hi, > > IMO, the first save area should always be below the line. > It is provided by the operating system so that the main program of the > called application (EXEC PGM=...) can store the registers on call there. > And the first program may be AMODE 24 :-) > > On the other hand, I would never use TCBFSA to do anything with it. > Because, for example, you would try to walk the save area chain from there, > you are stuck, because the forward pointers are not set correctly by LE > and others. > What you should do instead: fetch register 13 and walk back, by using the > backward > pointers, which are much more reliable in the general case. When doing > this, > you could check for the value in TCBFSA to see, if you arrived at the > first save > area. But you could also check for NULL in the backward pointer. > > HTH, kind regards > > Bernd > > > > Am 13.02.2018 um 10:07 schrieb Steff Gladstone: > >> Hi, >> >> I am in the process of converting several routines to AMODE=31 RMODE=ANY. >> One of them references the address of the first problem program save area >> found in the TCB. >> >> The field is defined as follows: >> >> TCBFSA DS0A -ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA >> >> DSFL1 - FIRST BYTE OF TCBFSA >> @G381P9A >> >> TCBFSAB DSAL3 - ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA >> >> My question: what is the status of the first byte? It does not seem to >> contain flag bits as is often the case. On the other hand, defining the >> field TCBFSAB seems to imply that the address is a 24-bit address. So in >> AMODE=31 can the first problem program save area (which is provided by the >> system to the top-level program) be above the line? Should I relate to >> all >> four bytes as the address of the FSA? Or could the first byte contain >> garbage? >> >> Thanks, >> Steff >> >> -- >> 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
TCBFSA field in the TCB DSECT
Hi, I am in the process of converting several routines to AMODE=31 RMODE=ANY. One of them references the address of the first problem program save area found in the TCB. The field is defined as follows: TCBFSA DS0A -ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA DSFL1 - FIRST BYTE OF TCBFSA @G381P9A TCBFSAB DSAL3 - ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA My question: what is the status of the first byte? It does not seem to contain flag bits as is often the case. On the other hand, defining the field TCBFSAB seems to imply that the address is a 24-bit address. So in AMODE=31 can the first problem program save area (which is provided by the system to the top-level program) be above the line? Should I relate to all four bytes as the address of the FSA? Or could the first byte contain garbage? Thanks, Steff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Looking for an appropriate system exit
Greetings, In our installation we would like to implement certain checks and document certain run-time characteristics at the beginning and during program initialization and duration (chiefly Cobol programs). We would like to implement this in a manner transparent to the application, without requiring the programmer to add lines of JCL or calls to subroutines (we have thousands of legacy programs and jobs and don't want to have to go through a massive conversion project). We are looking at initialization routines like CEEBINT. Can anyone recommend any other system exits that could be candidates for this sort of thing. Any potential pitfalls we should be aware of? Thank you, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Cobol 5/6 - Compile listing integrated into load module
In versions 5 and 6 of Cobol, IBM has introduced the option of including the compile listing (or at least the data from which a compile listing can be derived) into the load module for subsequent debug processing. Presumably this obviates the need to maintain something like the DDIO file required by Compuware's Expeditor product. My question is: does anybody know where this option is documented in detail, including: - all of the various compile-time parameters provided for specifying this option - how the compile information in the load module can be retrieved? Or is this totally proprietary information that IBM keeps under tabs? Thanks in advance for any assistance, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBDSACB control block
Does anybody know where we can find precise and complete information regarding the contents of the COBDSACB control block of COBOL? Thank you, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CEEBINT
We are considering using the user exit CEEBINT. Is there anyone out there with experience using the exit who could point us to the appropriate documentation detailing how to use it as well as any other suggestions as to its use? Thanks, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
A further question regarding COBOL5 and CEEDUMP
A further question: the CEEDUMP we receive in COBOL 5 lacks a dump of the WORKING STORAGE SECTION. Can this be remedied by changing compile-time or run-time parameters? Please advise. Thank you, Steff Gladstone On Sun, Jan 8, 2017 at 6:51 PM, Steff Gladstone <steff.gladst...@gmail.com> wrote: > Are there any whizzes out there who specialize in reading and deciphering > CEEDUMPs? > I have a question for you. In a COBOL5 CEEDUMP, how do I locate the > *index* of an array (i.e., an array that is defined with "indexed by") in > the dump? > > Thanks in advance, > Steff Gladstone > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL5 and ceedump
Are there any whizzes out there who specialize in reading and deciphering CEEDUMPs? I have a question for you. In a COBOL5 CEEDUMP, how do I locate the *index* of an array (i.e., an array that is defined with "indexed by") in the dump? Thanks in advance, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Recommended logstream policy for SYSVIEW statistical historical data
We are moving from TMON to SYSVIEW and are encountering very long processing times when we attempt to generate batch reports from Sysview statistical data that accumulated during the previous day (the data is written to a System Logger logstream). Apparently the report utility is starting its scan of the data from a much earlier date. What would be the recommended logstream policy for a logstream of this type? Is our assumption correct that this is an active (as opposed to funnel-type) logstream application? Thanks in advance for any assistance, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
InfoSphere Classic CDC for z/OS
Does anyone have any experience with the above software, as a tool to capture updates to a "classic" VSAM file on the mainframe and propagate them to a open-systems data base? Thanks, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Freeing up space in a VSAM file
Greetings, We have a KSDS file that gradually fills up with records. After deleting a large number of records we still received nonzero response codes when trying to add new records indicating that there is no available space in the file. We have no alternative but to disable access to the file and reorganize it, causing quite a disruption to operations. Presumably this is because of the way the indexes are organized. Any advice? What parameters do you suggest we "play" with to ameliorate the situation? Thanks in advance, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
Even without modifying the SWA with information for the DD, as you suggested earlier? On Tue, Apr 21, 2015 at 2:50 PM, John McKown john.archie.mck...@gmail.com wrote: On Tue, Apr 21, 2015 at 3:00 AM, Steff Gladstone steff.gladst...@gmail.com wrote: Thank you all for for help. The obvious question that remains is: how does the operating systen itself maintain a continuous ENQ over several job steps for a dataset allocated in the first step with disp=(mod,pass)? Is there a special privileged ENQ operation that only the operating system has access to? No, there is not a special ENQ. The initiator TCB, which exists for as long as the initiator is running, issues the ENQ. The initiator (in general terms) is what reads the parsed JCL and creates the SWA control blocks which represent the job. This code then knows the DSNs in the job and issues a single ENQ for _all_ of them before starting the first step. As each step ends, the initiator does a DEQ on the DSNs which are not going to be used in subsequent steps. At the end of the job, it DEQs whatever DSNs are left. This means that you _could_ use a directed ENQ to put the DSN on the ENQ chain for the initiator TCB, as you mentioned in a previous post. But since the initiator does not know anything about that, it will not know to do a DEQ to release it at end of job. This is why you would need a terminating step to do the DEQ. Thinking about it a bit more, given what Mr. Relson said about RTM, doing this _should_ work even if the initiator terminates abnormally since RTM should clean up the ENQs during EOM processing. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- 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
Fwd: ENQ for the life of the job
Greetings, How do I use the ISGENQ macro in such a way that the ENQ lasts for the life of the entire job (or several job steps) and not just for the life of a single job-step? Would specifying the TCB address of the initiator TCB on the TCB parameter work? Any better ideas? Thanks, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
The ENQ has to be transparent to the JCL. Could I dynamically allocate a dataset with DISP=(OLD,PASS)? As I recall the dynamic allocation does not permit the use of PASS. On Mon, Apr 20, 2015 at 5:30 PM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: I guess you could do that, assign the initiator TCB to the ENQ, but what happens if the job abends before the step you do the DEQ in? I think this will work - If the purpose is to prevent two similar processes, then why not use a common data set and allocate it as DISP=(OLD,PASS). That way the ENQ on the data set will last for the duration of the job, and if it dies early the ENQ automatically goes away. Chris Blaicher Technical Architect Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steff Gladstone Sent: Monday, April 20, 2015 10:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ENQ for the life of the job How do I use the ISGENQ macro in such a way that the ENQ lasts for the life of the entire job (or several job steps) and not just for the life of a single job-step? Would specifying the TCB address of the initiator TCB on the TCB parameter work? Any better ideas? Thanks, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- 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: ENQ for the life of the job
I suppose a final job-step to do the DEQ with COND=EVEN would not always do the trick. As I recall there are some types of abends that flush the job including steps with COND=EVEN, right? On Mon, Apr 20, 2015 at 6:09 PM, John McKown john.archie.mck...@gmail.com wrote: On Mon, Apr 20, 2015 at 9:41 AM, Steff Gladstone steff.gladst...@gmail.com wrote: The ENQ has to be transparent to the JCL. Could I dynamically allocate a dataset with DISP=(OLD,PASS)? As I recall the dynamic allocation does not permit the use of PASS. Hum, I'm going to go way out on a limb and start sawing. grin/ I wonder if it would be possible to do a directed ENQ of a SYSDSN to the initiator TCB and then modify the SWA to generate the internal information for a DD and place that as if it had been in a DD in the JCL. I am likely not saying that very well. But I'm thinking that products like CA-11 do this sort of thing for restart (in order to change GDG generation numbers). If this were possible, then perhaps the initiator would do the DEQ at end of job. Perhaps Chris, or another ISV person, would know. On Mon, Apr 20, 2015 at 5:30 PM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: I guess you could do that, assign the initiator TCB to the ENQ, but what happens if the job abends before the step you do the DEQ in? I think this will work - If the purpose is to prevent two similar processes, then why not use a common data set and allocate it as DISP=(OLD,PASS). That way the ENQ on the data set will last for the duration of the job, and if it dies early the ENQ automatically goes away. Chris Blaicher -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- 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: ENQ for the life of the job
The job is performing a change management system operation (moving a new program version to production, saving previous generations, providing for possible fallback, etc.). The operation for various reasons must be performed in several job steps. We want to ENQ on the name of the program being handled to prevent other operations or changes being made to that program in parallel. Of course the ENQ must remain in effect for the duration of the entire operation. On Mon, Apr 20, 2015 at 6:19 PM, Jousma, David david.jou...@53.com wrote: Maybe if you can explain in more detail what situation you are trying to solve for would help? _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steff Gladstone Sent: Monday, April 20, 2015 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENQ for the life of the job I suppose a final job-step to do the DEQ with COND=EVEN would not always do the trick. As I recall there are some types of abends that flush the job including steps with COND=EVEN, right? On Mon, Apr 20, 2015 at 6:09 PM, John McKown john.archie.mck...@gmail.com wrote: On Mon, Apr 20, 2015 at 9:41 AM, Steff Gladstone steff.gladst...@gmail.com wrote: The ENQ has to be transparent to the JCL. Could I dynamically allocate a dataset with DISP=(OLD,PASS)? As I recall the dynamic allocation does not permit the use of PASS. Hum, I'm going to go way out on a limb and start sawing. grin/ I wonder if it would be possible to do a directed ENQ of a SYSDSN to the initiator TCB and then modify the SWA to generate the internal information for a DD and place that as if it had been in a DD in the JCL. I am likely not saying that very well. But I'm thinking that products like CA-11 do this sort of thing for restart (in order to change GDG generation numbers). If this were possible, then perhaps the initiator would do the DEQ at end of job. Perhaps Chris, or another ISV person, would know. On Mon, Apr 20, 2015 at 5:30 PM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: I guess you could do that, assign the initiator TCB to the ENQ, but what happens if the job abends before the step you do the DEQ in? I think this will work - If the purpose is to prevent two similar processes, then why not use a common data set and allocate it as DISP=(OLD,PASS). That way the ENQ on the data set will last for the duration of the job, and if it dies early the ENQ automatically goes away. Chris Blaicher -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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
