Re: Continuing a reply during IPL
On Sat, 4 May 2024 03:55:45 -0500, Giliad Wilf wrote: >On Mon, 22 Apr 2024 15:17:47 +0300, Binyamin Dissen > wrote: > >>Saw the example, tried with and without quotes. No luck. >> >. >. >. >Sorry, I only saw this post yesterday. >I've forced IPL to issue msg. IEA101A by changing IMSI char. from M to T in >IPL parameter. >First, I've specified SYSP=DW, because our LOADxx specifies 'SYSPARM DW'. >The list of SYSP suffixes must be completed on a single response and can't be >split... > . . . Much to my embarrassment I did not test the same case. After deliberately messing with the PROG list, replacing a comma with a period, I could not respecify the PROG list split into two and had to respecify the entire list in a single response...[sigh]. Fortunately enough, respecifying the entire list did not exceed 80 chars. (the maximum)... >-- >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: Continuing a reply during IPL
On Mon, 22 Apr 2024 15:17:47 +0300, Binyamin Dissen wrote: >Saw the example, tried with and without quotes. No luck. > . . . Sorry, I only saw this post yesterday. I've forced IPL to issue msg. IEA101A by changing IMSI char. from M to T in IPL parameter. First, I've specified SYSP=DW, because our LOADxx specifies 'SYSPARM DW'. The list of SYSP suffixes must be completed on a single response and can't be split. Then I asked for a MLPA list split onto two responses, followed by a long PROG list split onto two responses too. Here's how it went: IEA371I SYS1.IPLPARM ON DEVICE 0A82 SELECTED FOR IPL PARAMETERS IEA246I LOAD ID DW SELECTED IEA246I NUCLST ID 00 SELECTED IEA519I IODF DSN = SYS1.IODF02 IEA520I CONFIGURATION ID = OS390 . IODF DEVICE NUMBER = 0A82 IEA091I NUCLEUS 1 SELECTED IOS128I IPL DEVICE: 00A80 VOLUME: A3RES1 IEA370I MASTER CATALOG SELECTED IS CATALOG.Z31A.MASTER | IEA101A SPECIFY SYSTEM PARAMETERS FOR z/OS 03.01.00 HBB77E0 R 0,'SYSP=DW,CONT' IEE600I REPLY TO 00 IS;SYSP=DW,CONT | IEA116A CONTINUE SYSTEM PARAMETERS R 0,'MLPA=(00,CONT' IEE600I REPLY TO 00 IS;MLPA=(00,CONT | IEA116A CONTINUE SYSTEM PARAMETERS R 0,'DI,L),PROG=(AB,AC,AD,AM,AN,A0,A1,A2,ZW,CONT' IEE600I REPLY TO 00 IS;DI,L),PROG=(AB,AC,AD,AM,AN,A0,A1,A2,ZW,CONT | IEA116A CONTINUE SYSTEM PARAMETERS R 0,'SY,LB,LC,LD,LM,LN,L0,L1,L2,LL)' IEE252I MEMBER IEASYS00 FOUND IN ADCD.Z31A.PARMLIB IEE252I MEMBER IEASYSDW FOUND IN USER.Z31A.PARMLIB IEA007I STATIC SYSTEM SYMBOL VALUES 020 &SYSALVL. = "2" &SYSCLONE. = "1A" &SYSNAME. = "S0W1" &SYSOSLVL. = "Z1030100" . . . ...and here are excerpts from SDSF's SYSP command showing the result: MLPA (00,DI) PROG (AB, PROG AC, PROG AD, PROG AM, PROG AN, PROG A0, PROG A1, PROG A2, PROG ZW, PROG SY, PROG LB, PROG LC, PROG LD, PROG LM, PROG LN, PROG L0, PROG L1, PROG L2, PROG LL) Regards, Giliad -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS Enhanced HOLDDATA
Ah, seems to be a problem of Chrome, or a matter of Chrome's cache. Edge did not have any problem showing this stuff Thank you. On Sun, 1 Nov 2020 09:57:59 +, Gadi Ben-Avi wrote: >It's still there. >Get the full file from ftp://public.dhe.ibm.com/s390/holddata/full.txt or >ftp://public.dhe.ibm.com/s390/holddata/full.bin > >Gadi > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Giliad Wilf >Sent: Sunday, November 1, 2020 11:51 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: z/OS Enhanced HOLDDATA > >Hi All, > >Where can I find the z/OS accumulated enhanced holddata? > >It used to be on the below page... > >http://service.software.ibm.com/holdata/390holddata.html > >...on a table wherehthere was one packaging form in plain test for 730 days >that included FIXCATs. > >This is not a matter of "site down ror Sunday maintenance", because I could >not get it on Friday and Saturday either. > >-- >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
z/OS Enhanced HOLDDATA
Hi All, Where can I find the z/OS accumulated enhanced holddata? It used to be on the below page... http://service.software.ibm.com/holdata/390holddata.html ...on a table where there was one packaging form in plain test for 730 days that included FIXCATs. This is not a matter of "site down for Sunday maintenance", because I could not get it on Friday and Saturday either. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM Personal Communications font
Hi All, Is it possible to configure PCOMM (V6, if it matters) to use a font of choice? Specifically, I'm interested in "Lucida Console" font, which displays better, clearer at any size. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Chaning time zone for Unix based tasks
On Mon, 30 Dec 2019 14:47:35 +, Allan Staller wrote: >One time setup. > >-Original Message- >From: I M Mainframe Discussion List On Behalf Of >Gadi Ben-Avi >Sent: Monday, December 30, 2019 1:33 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Chaning time zone for Unix based tasks > >Thanks >Is this a otetime setup, or would I have to do this twice a year? >Gadi > >One time setup. > Yes, it flips automatically, Gadi. Note the M3 and M10 in the expression, for March and October. What does not flip automatically is the CLOCKxx's TIMEZONE parameter value. A JES2 automatic command can be manually set, up to seven days in advance, before the date, to do the flip "unattended", as it has to occur at 2am... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Xpediter: Same Debugger from Competing Vendors???
On Wed, 25 Sep 2019 15:39:40 +, Seymour J Metz wrote: Well, SVC51 is a type-4 SVC and was comprised of several IGCnn05A pieces. I think there was a limit for the size of a single piece back at MVT R21 days, of 1K, or maybe 2K and it had to fit into something called "transient area". You could not do much with just 1K or 2K. Currently, there is no limit on the size of a type-4 svc... >WTG tables are characteristic of O/C/EOV; most type 4 SVC routines didn't >have one. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Giliad Wilf <00d50942efa9-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, September 25, 2019 9:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Xpediter: Same Debugger from Competing Vendors??? On Tue, 24 Sep 2019 20:29:18 -0500, David Staudacher wrote: If memory serves me right, the roots of Xpediter-type software are in a shop that wrote a module that had been inserted into SVC51's (SDUMP) control flow. In those days a large SVC routine was comprised of several pieces, each having a WTG (Where-To-Go) table at the end, comprised of several entries, with each entry containing the name and TTR of the next piece to be loaded and given control, based on decision made in the current piece. The shop wrote a new piece to be the 3rd to be given control on SVC51's flow, and redirected processing to code that enhanced debugging, then returned to the appropriate point on the normal flow through its own WTG table. A special utility IEHIOSUP had to be invoked to refit TTRs on modules' WTG tables after applying PTFs. >Earliest reference yet to "ADS Xpediter" - October 26, 1981 (lower left of >page): >http://secure-web.cisco.com/1uz-ox0PtaceSDeJuoNSnNZoWqfJhe5dAFCOUVYFUqK1qVk3pt4Zntiik0DcJLgVKzDNXQkBO0o2FRBN6hvY2_sdNZ7j_kA6zhXDUmBLQC7lg_i6erF5wVGM1HhBwm9B4Je3WujW2RMdbJqWxFWdl_2x4TzTf1_qN_WpaWdWhF4p2Ez5UUvRKgBAp8QSKQCR8jByjhNgqJwonwEgNuyqyKd55oR5ay3vCdIRfPZsxi01X5U89oXHLx9svqwQXLq6ZBDlaprv3dGZ4igk88ShV01agkRAhCvnk7KNyjx-JGE6asv0F8E6_kY5a4E_wnLyGJsoy9L1rpDSwwoSmIMPba3bgqOGLpG2GgsC4XcyEhH6GfwaLQCP5gL12-fnk3at2L7-6CLwMLxgO4MF40Ygo_ULQstiWlT61-KvRK2k8azdLDy6B_CJKkfKCKi18bM_8/http%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3D1REkdf3I86oC%26pg%3DPA46 > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Xpediter: Same Debugger from Competing Vendors???
On Tue, 24 Sep 2019 20:29:18 -0500, David Staudacher wrote: If memory serves me right, the roots of Xpediter-type software are in a shop that wrote a module that had been inserted into SVC51's (SDUMP) control flow. In those days a large SVC routine was comprised of several pieces, each having a WTG (Where-To-Go) table at the end, comprised of several entries, with each entry containing the name and TTR of the next piece to be loaded and given control, based on decision made in the current piece. The shop wrote a new piece to be the 3rd to be given control on SVC51's flow, and redirected processing to code that enhanced debugging, then returned to the appropriate point on the normal flow through its own WTG table. A special utility IEHIOSUP had to be invoked to refit TTRs on modules' WTG tables after applying PTFs. >Earliest reference yet to "ADS Xpediter" - October 26, 1981 (lower left of >page): >http://books.google.com/books?id=1REkdf3I86oC&pg=PA46 > >-- >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: Instruction speeds
Hi Brian, I did not see this sort of publications for three or four decades. Maybe IBM zServer engineers still use some instruction timing charts during chip design/development. As far as I'm concerned, my emphasis while coding is on clarity and readability. Regards, On Tue, 13 Aug 2019 10:52:05 -0400, Brian Chapman wrote: >Thanks Giliad. This is what I was searching for. I understand that the >timings in this document are very old and probably wildly inaccurate for >today's Z systems, but would it be on a relative scale? Would a LR be twice >the speed of a L? > > > >Thank you, > >Brian Chapman > > >On Tue, Aug 13, 2019 at 10:28 AM Giliad Wilf < >00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote: > >> On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman >> wrote: >> >> >Hi everyone, >> > >> >I did some searching, but I didn't find anything that really discussed >> this >> >on the topic that I'm interested. Is there anything published that >> compares >> >the cycle times of the most used instructions? >> > >> >For example; moving an address between areas of storage. I would assume >> >that executing a LOAD and STORE would be much quicker than executing a >> MVC. >> > >> >Or executing a LOAD ADDRESS to increment a register instead of ADD HALF >> >WORD. >> > >> >Or does this really matter as much as ordering the instructions so they >> are >> >optimized for the pipeline? >> > >> >> There used to be, with every new IBM System/360 machine, a "Functional >> Characteristics" publication stating "Instruction Times" in microseconds. >> Here is one for the IBM System/360 Model 85: >> >> >> http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf >> >> See page 27. >> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Instruction speeds
On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman wrote: >Hi everyone, > >I did some searching, but I didn't find anything that really discussed this >on the topic that I'm interested. Is there anything published that compares >the cycle times of the most used instructions? > >For example; moving an address between areas of storage. I would assume >that executing a LOAD and STORE would be much quicker than executing a MVC. > >Or executing a LOAD ADDRESS to increment a register instead of ADD HALF >WORD. > >Or does this really matter as much as ordering the instructions so they are >optimized for the pipeline? > There used to be, with every new IBM System/360 machine, a "Functional Characteristics" publication stating "Instruction Times" in microseconds. Here is one for the IBM System/360 Model 85: http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf See page 27. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch REXX, Consoles & SYSPLEX
On Mon, 15 Jul 2019 08:45:30 -0500, Elardus Engelbrecht wrote: >Veryl Ellis wrote: > >>The REXX Exec determines what processor and LPAR it is in and issues a >>'CONSOLE ACTIVATE', 'CONSOLE SYSCMD... (to start the appropriate TCPIP)' and >>a 'CONSOLE DEACTIVATE'. > >Please post the full commands+keywords as used for these 3 CONSOLE. > >>IKJ55303I CONSOLE command terminated. MCSOPER input parm contains error. >>RC=x'10', REASON CODE=x'38', which means "command associated in OPERPARM >>segment not valid". > >Put in a SAY showing the MCSOPER input and also post it here on IBM-MAIN. > >I think you may have already have a CONSOLE with the same name somewhere >active? Check it out with D EMCS command. > >Groete / Greetings >Elardus Engelbrecht > Could be. Consoles are ENQ-ed exclusively on QNAME=SYSZCNZ and RNAME=CONNAME#consolename. One has to issue... D GRS,RES=(SYSZCNZ,CONNAME#*) ...and look for possible sysplex-wide conflicts... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Job abend with S722
On Fri, 5 Jul 2019 19:06:04 +0530, raji ece wrote: >One of our job is abending with RC S722 and the error show the maximum >outlimit execeed. We have coded lines=99(Maximum limit) and run but >getting same error. Current zos level is 1.13. any idea? > Did the job ABEND before it has been given control? If a job has a lot of steps, each with a lot of DD statements that are using variable symbols, causing an additional "IEFC653I SUBSTITUTION JCL..." line to be produced for every statement using variable symbol(s), than output limit could be exceeded before the job gets control, since you can't specify OUTLIM for the JESJCL dataset. Installation EXIT9 should tolerate such a condition. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO for message that will require explicit deletion?
On Wed, 26 Jun 2019 14:39:24 -0700, Charles Mills wrote:
>I have an APF-authorized batch program that I want to have WTO a message
>that will hang out at the bottom of the console screen until it is
>explicitly deleted. Can I do that?
>
>
>
>The doc for DESC=(3) seems to kind of say that ("If the task can determine
>when the operator has performed the action, the task should issue a DOM
>macro to delete the message") but it does not seem to be working for me.
>(ROUTCDE=(11) FWIW.)
>
>
>
>Is there a way to do it?
>
>
>
>Charles
>
Why ROUTCDE 11?
ROUTCDE 11 message is WTP (Write to Programmer) and is written to the JESYSMSG
data set.
Most consoles or EMCS interfaces exclude ROUTCDE 11 messages, although they get
written to the HARDCPY.
I think DESC 3 messages (EVENTUAL-ACTION-REQUIRED) get DOM-ed upon step end,
but long-running jobs that are up for the life of the IPL or so, will need to
DOM DESC-3 messages at some point...when the said ACTION has been taken...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tapemap control statement error
On Tue, 25 Jun 2019 08:34:52 -0500, Steve Horein wrote: >Found in one of my toolboxes: > >//STEP1 EXEC PGM=TAPEMAP >//SYSPRINT DD SYSOUT=1 >//SYSUT1DD VOL=SER=E07101, >// DISP=OLD, >// UNIT=CART, >// LABEL=(*1*,BLP,EXPDT=98000) >//* > No. Omitting dataset sequence number indicates the first data set on the tape volume. Maybe an ESM is involved in failing the request... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tapemap control statement error
On Tue, 25 Jun 2019 15:37:11 +1000, Wayne Bickerdike wrote: >Jake, > >your DD statemtnt looks wrong: > >Try: > >//SYSUT1 DD >DSN=A,LABEL=(,BLP,EXPDT=98000),UNIT=VTAPE,VOL=SER=P098878,DISP=(OLD,PASS) > >On Mon, Jun 24, 2019 at 2:04 PM Jake Anderson >wrote: > >> Hi >> >> I am running this JCL to obtain information about a virtual tape. >> >> //JOBCARD >> // STEP EXEC PGM=TAPEMAP >> //SYSPRINT DD SYSOUT=* >> //SYSPRINT2 DD SYSOUT=* >> //SYSUT1 DD >> LABEL=(,BLP,EXPDT=98000),UNIT=VTAPE,VOL=SER=P098878,DISP=(OLD,PASS) >> >> The error I get is >> >> ** DEVICE TYPE WAS NOT SPECIFIED >> ** ERROR DETECTED BY PARAMETER CONVERTER, PROCESSING ABORTED >> >> Is there anything missed out in my JCL as I have specified UNIT . >> >> Jake >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > >-- >Wayne V. Bickerdike Since label processing is being bypassed, DSN can be any syntactically valid name, but why is volser 7-char long? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Alias Listcat discrepancy betweeen sysplex'd LPARs
On Mon, 10 Jun 2019 23:32:21 -0500, Elaine Beal wrote: >These LPARs do share a master catalog. >LOADxx syscat has the same parm on both LPARs > >A listcat of the master shows the alias entry > >ALIAS -,SYS7.R30 > >Thanks, >Elaine > Can you please show us the complete LOADxx member each LPAR is using? I'm specifically interested in the SYSCATs' multilevel alias value (at pos. 17), but prefer to see the entire LOADxxs, if no "trade secrets" involved. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
A VTF Mainframe (VTFM) question
Hi All, I've been assigned to evaluate VTF Mainframe (VTFM) at our shop and it is already installed and running. Looking for things that have been set "under the hood" I can see its subsystem has four SSI routines: No. 9, "Notify write-to-operator message". No. 10, "Notify operator command". No. 252, ??? No. 254, ??? Obviously, The last two are servicing some "private requests", not of the usual "well known" types. Does anyone have an idea what are these two for? Giliad -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NETSTAT command
On Mon, 18 Mar 2019 14:03:10 +, Nai, Dean wrote: >Anyone ever run into a problem where the NETSTAT command hangs? We use it in >some scripts to check if things are up or not but to stopped working last >Friday. When we issue it using TSO NETSTAT or issue it from OMVS it just >hangs. Any thoughts? > >Dean Nai > Could this be of any help? http://www.redbooks.ibm.com/tips/TIPS0091/tips0091.pdf -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM69168E messages on COBOL V6.2 upgrade
On Fri, 15 Mar 2019 07:42:02 -0500, Vinoth Meenakshi wrote: >when i searched for reason code 0594003D its sounds > >BPXFVLKP 10/27/17 > >JRDirNotFound: A directory in the pathname was not found > > > >Action: One of the directories specified was not found. Verify that the name >specified is spelled correctly. >*** >*** > >Here is BPXPRINT. > >1BPXF151I BPXCOPY WAS INVOKED FOR HEAD ID 65. > BPXF150I MVS DATA SET WITH DDNAME SMP2 SUCCESSFULLY COPIED INTO BINARY > HFS FILE /SYTIX1/usr/lpp/IBM/cobol/igyv6r2/bin/IBM/IGYACT > . >1BPXF151I BPXCOPY WAS INVOKED FOR HEAD ID 66. > BPXF150I MVS DATA SET WITH DDNAME SMP2 SUCCESSFULLY COPIED INTO BINARY > HFS FILE /SYTIX1/usr/lpp/IBM/cobol/igyv6r2/bin/IBM/IGYCHK > JA. >1BPXF151I BPXCOPY WAS INVOKED FOR HEAD ID 67. > BPXF150I MVS DATA SET WITH DDNAME SMP2 SUCCESSFULLY COPIED INTO BINARY > HFS FILE /SYTIX1/usr/lpp/IBM/cobol/igyv6r2/bin/IBM/IGYCKA > CT. >1BPXF151I BPXCOPY WAS INVOKED FOR HEAD ID 68. > BPXF150I MVS DATA SET WITH DDNAME SMP2 SUCCESSFULLY COPIED INTO TEXT HFS > FILE /SYTIX1/usr/lpp/IBM/cobol/igyv6r2/bin/IBM/IGYCOB2J > . > BPXF140E RETURN CODE 0081, REASON CODE 0594003D. A LINK FAILED FOR LINK > NAME /SYTIX1/usr/lpp/IBM/cobol/igyv6r2/bin/IBM/../../li > b/nls/msg/Ja_J. > Could this be of any help? It talks about reason code 0594003D too: http://www-01.ibm.com/support/docview.wss?uid=swg21195928 BPXCOPY will look for the DDDEF for SIGYHFS, which ends with '.../bin/IBM/', back two directory levels, and will expect to see there directories 'demo', 'include', 'lib' and 'bin'... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: curiosity question about tape drive displays.
"RETAIN" here actually means "leave the volume mounted on the device, and unwound"...pending possible further usage in one of the next jobsteps... On Fri, 9 Nov 2018 23:25:06 -0500, Tony Thigpen wrote: . . >Position 1 can be: >Blank = Verify >M = Mount >D = Demount >K = Keep (put in rack) >R = Retain (keep near by for additional use) > . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
Interesting. I recall two statements, probably from two different sources: One states that BDAM does not support large format datasets. The other states that DA datasets accessed by relative track address are limited to 65536 tracks. ...so, I must assume ADABAS has a way for accessing records of a dataset that large... On Fri, 2 Nov 2018 11:32:23 +, Mick Graley wrote: >Hi All, > >I can confirm that there is no 64K tracks limit on DSORG=DA data sets. >I inherited a number of Adabas databases and they use DSORG=DA. >One of my larger databases has a data storage component that is 240,525 >tracks (16,035 cylinders) in 9 extents across 8 volumes. > >Organization . . . : DA >Record format . . . : F >Record length . . . : 5064 >Block size . . . . : 5064 >1st extent cylinders: 363 >Secondary cylinders : 1668 >Allocated cylinders : 16,035 >Allocated extents . : 9 > >The rules are documented here: >https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm > >Cheers, > >Mick. > > >On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: > >> BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files are >> usually physically equivalent to DSORG PS, and often are so designated. >> However, most DA files I've seen are indeed RECFM=F. >> >> sas >> >> On Fri, Oct 26, 2018 at 11:40 AM Tom Sims wrote: >> >> > Datacom may use some method of "direct access," but the datasets >> > themselves are RECFM=F. >> >> -- >> 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: VOLCAT split
Maybe it became too "crowded" and one sees alarming message IEC361I...or it became a performance issue... On Fri, 2 Nov 2018 08:11:38 +, Vernooij, Kees (ITOPT1) - KLM wrote: >Just out of curiosity: why do you want to split VOLCAT? > >Kees. > > > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of R.S. >> Sent: 01 November, 2018 21:50 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: VOLCAT split >> >> I have single file volcat, that means hlq.VOLCAT.VGENERAL. >> How can I split the general volcat into specific volcats? >> >> Anther question: how can I move volcat (general) to another volume? >> >> -- >> Radoslaw Skorupka >> Lodz, Poland >> >> >> >> >> == >> >> Je�li nie jeste� adresatem tej wiadomo�ci: >> >> - powiadom nas o tym w mailu zwrotnym (dzi�kujemy!), >> - usu� trwale t� wiadomo�� (i wszystkie kopie, kt�re wydrukowa�e� lub >> zapisa�e� na dysku). >> Wiadomo�� ta mo�e zawiera� chronione prawem informacje, kt�re mo�e >> wykorzysta� tylko adresat.Przypominamy, �e ka�dy, kto rozpowszechnia >> (kopiuje, rozprowadza) t� wiadomo�� lub podejmuje podobne dzia�ania, >> narusza prawo i mo�e podlega� karze. >> >> 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, KRS >> 025237, NIP: 526-021-50-88. Kapita� zak�adowy (op�acony w ca�o�ci) >> wed�ug stanu na 01.01.2018 r. wynosi 169.248.488 z�otych. >> >> If you are not the addressee of this message: >> >> - let us know by replying to this e-mail (thank you!), >> - delete this message permanently (including all the copies which you >> have printed out or saved). >> This message may contain legally protected information, which may be >> used exclusively by the addressee.Please be reminded that anyone who >> disseminates (copies, distributes) this message or takes any similar >> action, violates the law and may be penalised. >> >> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00- >> 950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for >> the Capital City of Warsaw, 12th Commercial Division of the National >> Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share >> capital amounting to PLN 169,248,488 as at 1 January 2018. >> >> -- >> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DEVSUPxx question
In short, your DEVSUPxx should have been coded like this: NON_VSAM_XTIOT=YES, COMPACT=YES, MEDIA1=11, MEDIA2=12 ...rather than like this: NON_VSAM_XTIOT=YES, COMPACT=YES, MEDIA1=11, MEDIA2=21 See a sketch here, at https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3SC236867/$file/idao300_v2r3.pdf on publication's page 74 (PDF physical page 94), showing how a tape library is being shared between several sysplexes or systems, while each having its own partition... On Wed, 31 Oct 2018 06:15:53 +, Gadi Ben-Avi wrote: >Hi, >I coded > >NON_VSAM_XTIOT=YES, >COMPACT=YES, >MEDIA1=11, >MEDIA2=21 > >In DEVSUP00 and then issued the command SET DEVSUP=00 > >How can I be sure that the values for MEDIA1 and MEDIA2 were accepted? > >I am running z/OS v2.2 > >Thanks > >Gadi > >? ?? ? ?? ??? ??? ?? ? ??? ?? >??. ?? , ?? ??? ?, ??? ? ?? ??? >? ?? ?? ?. ? ? ?? ?? ?? ?? ?? >??? ??? ???, ?/?? ?, ? ?? ? ? ? ? ?? ?? ? >??? ?/?? ?? ?? ??. > >-- >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: DEVSUPxx question
Sorry, finger check. it should have been: ...and the last digit 'n' to the right of the ppp at the right side of the "=" rather than ...and the last digit 'n' to the right of the ppp at the left side of the "=" On Wed, 31 Oct 2018 13:23:46 -0500, Giliad Wilf wrote: >As far as I can recall, a media statement in DEVSUPxx has the format: > >MEDIA1=ppp1, >MEDIA2=ppp2, >.. >.. >MEDIA13=pppD > >...where ppp stands for partition No., and the last digit 'n' to the right of >the ppp at the left side of the "=", must match the 'n' of MEDIAn to the left >of the "=" (or maybe my memory does not serve me right, does it?)... > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DEVSUPxx question
As far as I can recall, a media statement in DEVSUPxx has the format: MEDIA1=ppp1, MEDIA2=ppp2, .. .. MEDIA13=pppD ...where ppp stands for partition No., and the last digit 'n' to the right of the ppp at the left side of the "=", must match the 'n' of MEDIAn to the left of the "=" (or maybe my memory does not serve me right, does it?)... On Wed, 31 Oct 2018 06:15:53 +, Gadi Ben-Avi wrote: >Hi, >I coded > >NON_VSAM_XTIOT=YES, >COMPACT=YES, >MEDIA1=11, >MEDIA2=21 > >In DEVSUP00 and then issued the command SET DEVSUP=00 > >How can I be sure that the values for MEDIA1 and MEDIA2 were accepted? > >I am running z/OS v2.2 > >Thanks > >Gadi > >? ?? ? ?? ??? ??? ?? ? ??? ?? >??. ?? , ?? ??? ?, ??? ? ?? ??? >? ?? ?? ?. ? ? ?? ?? ?? ?? ?? >??? ??? ???, ?/?? ?, ? ?? ? ? ? ? ?? ?? ? >??? ?/?? ?? ?? ??. > >-- >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: We're IST-2IDT, and switching back from UTC+3 to UTC+2 at 2AM Oct. 28th
Here is something confusing me for several years: The publication https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxa400/dtcutz.htm states TZ should be set at your /etc/csh.login, but I will add your suggestion (/etc/rc) to my list of locations requiring modification whenever TZ's startdate/enddate are to be adjusted, just to be on the safer side. Thank You and all contributors of insights into this issue. On Mon, 29 Oct 2018 12:32:41 +, Allan Staller wrote: >You also need to modify /etc/rc > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Giliad Wilf >Sent: Sunday, October 28, 2018 4:40 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: We're IST-2IDT, and switching back from UTC+3 to UTC+2 at 2AM >Oct. 28th > >Yes, > >I did set TZ to IST-2TDT five months ago on /etc/profile, and at additional >places , such as: > >/etc/init.options >/etc/httpd.envvars >/etc/csh.login >/usr/local/zoneinfo > >...and, of cosrse, also on CEEDOPT, CEECOPT, and on CELQDOPT sectors of >CEEPRM00...to no avail. > >Something is still missing. >I can't believe an IPL is required for USS to pick timezone switch back. > > >On Sun, 28 Oct 2018 08:45:17 +,aGadi Ben-Avi wrote: > >>For USS stuff, look in /etc/profile. There might be a TZ varable being set >>there. >> >>-Original Message- >>From: IBM Mainframe Discussion List On >>Behalf Of Giliad Wilf >>Sent: Sunday, October 28, 2018 10:26 AM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: We're IST-2IDT, and switching back from UTC+3 to UTC+2 at >>2AM Oct. 28th >> >>Well, something did not work as I expected. >>(My original post: >>https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist >>serv.ua.edu%2Fcgi-bin%2Fwa%3FA2%3Dind1810%26L%3DIBM-MAIN%26O%3DD%26P%3D >>420113&data=02%7C01%7Callan.staller%40HCL.COM%7C92275959a09c4ce5a5c >>a08d63cb94ffd%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636763163967 >>475966&sdata=QWDCq95Cyept91rYe3HgFb7%2FmdHYS%2BOKnPRRrZF7GEk%3D& >>;reserved=0 ) >> >>The command... >>$TA STTZ,T=98.00,'$VS,''SET TIMEZONE=E.02.00''' >>...issued on Wed. Oct. 24th did switch local time back from IDT (UTC+3) to >>IST (UTC+2) this morning at 2AM (local time switched back to 1AM), and I've >>corrected TIMEZONE statement at CLOCK00 to read "E.02.00.00" rather than >>"E.03.00.00", but USS still thinks we're on IDT. >> >>Here are some USS commands I've issued this morning (I did not change >>anything on USS parameters since May): >> >>IBMUSER:/u/ibmuser: >env >>MAIL=/usr/mail/IBMUSER >>_BPX_TERMPATH=OMVS >>PATH=/Z22D/opt/SP/bin:/Z22D/opt/GIT/bin:/bin:. >>SHELL=/bin/sh >>PS1=$LOGNAME:$PWD: > >>COLUMNS=134 >>_=/bin/env >>LOGNAME=IBMUSER >>STEPLIB=none >>LANG=C >>LIBPATH=/lib:/usr/lib:. >>TERM=dumb >>HOME=/u/ibmuser >>LINES=62 >>TZ=IST-2IDT >>MANPATH=/usr/man/%L >>NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat >>TR_Options=noResumableTrapHandler >>IBMUSER:/u/ibmuser: >date >>Sun Oct 28 10:56:09 IDT 2018 >>IBMUSER:/u/ibmuser: >date -u >>Sun Oct 28 07:56:18 GMT 2018 >>IBMUSER:/u/ibmuser: > >> >>=End of Display = >> >>UTC is correct, and one can see 'TZ=IST-2IDT', and everything on z/OS is >>absolutely OK, except for USS. >>USS still thinks we're three hours East. >> >>Is IPL required anyway (which I don't believe is necessary), or am I missing >>something obvious ? >> >>Regards, >>Giliad >> >>On Thu, 25 Oct 2018 02:39:41 -0500, Giliad Wilf wrote: >> >>>Good question. >>>Developers here do not rely on local time, but I want them to always see >>>local time. >>>It has something to do with human perception of "reality". >>> >>>Giliad >>> >>>On Wed, 24 Oct 2018 16:30:24 -0500, Paul Gilmartin >>>wrote: >>> >>>>On Wed, 24 Oct 2018 02:38:39 -0500, Giliad Wilf wrote: >>>>> >>>>>At 2AM on Sunday, Oct. 28th, Israel is switching from IDT to IST. >>>>>... >>>>>... We ... as far as I know, do not rely on local time. >>>>> >>>>??? >>>> >>>>If you "do not rely on local time", how can timezones and offsets matter to >>>>you? >>>> >>>>-- gil >>>> >>>>
Re: SVC99 DEALLOC Failure
0388 is a class-3 error (invalid parameter list), assigned by DAIR, meaning "A required key not specified for any of the following requests": ddname allocation, information retrieval, concatenation, deconcatenation, remove In - Use, unallocation. On Mon, 29 Oct 2018 16:02:30 -0400, Steve Thompson wrote: >I'm testing a special in-house developed utility. So it is >designed to be invoked by a COBOL program. > >I'm going to tell you how I got here and all the stuff I've been >doing, and then the effects of the SIS (IBMLink search), etc. >before I ask my question. > >So a test of the code, once fixed to run AMODE=31, works when I >do an allocation of one of my own data sets using the DD of SYSUT1. > >When I do this allocate, I do not specify anything special for >the text units. I only use the DDNAME, DSNAME and disposition of SHR. > >Now, I come back and test the DEALLOC function, and I get a >failure from SVC99, and in the RBX I get ERROR CODE 0388 - ALL >REQUESTS EXCEPT DSNAME ALLOCATIONS REQUIRED KEY NOT SPECIFIED (I >know this because the program has SNAP logic built in so I can >SNAP the Text units & pointers before and after the SVC99 >execution). This is also associated with IKJ56878I and that >message makes no sense. > >But the doc for that message says go read the text messages in >the manual, and basically, pay attention to the text keys that >are required. > >Uh, it appears that only the DDNAME is required, but it doesn't >say you can't also specify the DSNAME. It makes no difference, I >can't get this to work. > >So, the message manual also says something about DAIRFAIL. Well I >haven't played with DAIR directly for so long that I can't >remember what manual(s) even hold that info, if they are even >published these days. > >Ok, so I did a bunch of duckduckgo.com searches, and google, and >I can't find anything that matches. > >So then I went to IBMLink and finally got the web pages to >display formatted (Chrome) and searched and got no hits for the >message, for dairfail, etc. And I was not just looking for APARs >and PTFs, I was including other libraries for info as well. > >[KC comes into this now, and it locked up IE.] So back to Chrome >and I can't find the info I need. > >Does anyone know if there is something special about SYSUTn as a >DD for SVC99? I use these all the time via REXX, and I don't have >these problems there. > >So it would seem that it should be simple as I did not turn on >any special flags for doing the allocation (e.g., in-use, or >similar). > >Regards, >Steve Thompson > >-- >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: We're IST-2IDT, and switching back from UTC+3 to UTC+2 at 2AM Oct. 28th
My fault ! TZ had to be expressed with startdate and enddate like this: IST-2IDT,M3.4.5,M10.5.0 ...where M.3.4.5 means start date is month 3, week 4, day 5 (Friday) ...and M10.5.0 means end date is month 10, week 5, day 0 (Sunday). I suddenly recalled raising this issue half a year ago, searched the archives and found what was missing. Maybe I'm dealing with too many issues in parallel, and this one slipped away. Sigh...why couldn't USS pick this info from the CVTTZ? Why is it necessary to maintain this switching date in two different formats? On Sun, 28 Oct 2018 04:39:30 -0500, Giliad Wilf wrote: >Yes, > >I did set TZ to IST-2IDT five months ago on /etc/profile, and at additional >places , such as: > >/etc/init.options >/etc/httpd.envvars >/etc/csh.login >/usr/local/zoneinfo > >...and, of course, also on CEEDOPT, CEECOPT, and on CELQDOPT sectors of >CEEPRM00...to no avail. > >Something is still missing. >I can't believe an IPL is required for USS to pick timezone switch back. > > >On Sun, 28 Oct 2018 08:45:17 +, Gadi Ben-Avi wrote: > >>For USS stuff, look in /etc/profile. There might be a TZ varable being set >>there. >> >>-Original Message- >>From: IBM Mainframe Discussion List On Behalf Of >>Giliad Wilf >>Sent: Sunday, October 28, 2018 10:26 AM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: We're IST-2IDT, and switching back from UTC+3 to UTC+2 at 2AM >>Oct. 28th >> >>Well, something did not work as I expected. >>(My original post: >>https://listserv.ua.edu/cgi-bin/wa?A2=ind1810&L=IBM-MAIN&O=D&P=420113 ) >> >>The command... >>$TA STTZ,T=98.00,'$VS,''SET TIMEZONE=E.02.00''' >>...issued on Wed. Oct. 24th did switch local time back from IDT (UTC+3) to >>IST (UTC+2) this morning at 2AM (local time switched back to 1AM), and I've >>corrected TIMEZONE statement at CLOCK00 to read "E.02.00.00" rather than >>"E.03.00.00", but USS still thinks we're on IDT. >> >>Here are some USS commands I've issued this morning (I did not change >>anything on USS parameters since May): >> >>IBMUSER:/u/ibmuser: >env >>MAIL=/usr/mail/IBMUSER >>_BPX_TERMPATH=OMVS >>PATH=/Z22D/opt/SP/bin:/Z22D/opt/GIT/bin:/bin:. >>SHELL=/bin/sh >>PS1=$LOGNAME:$PWD: > >>COLUMNS=134 >>_=/bin/env >>LOGNAME=IBMUSER >>STEPLIB=none >>LANG=C >>LIBPATH=/lib:/usr/lib:. >>TERM=dumb >>HOME=/u/ibmuser >>LINES=62 >>TZ=IST-2IDT >>MANPATH=/usr/man/%L >>NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat >>TR_Options=noResumableTrapHandler >>IBMUSER:/u/ibmuser: >date >>Sun Oct 28 10:56:09 IDT 2018 >>IBMUSER:/u/ibmuser: >date -u >>Sun Oct 28 07:56:18 GMT 2018 >>IBMUSER:/u/ibmuser: > >> >>=End of Display = >> >>UTC is correct, and one can see 'TZ=IST-2IDT', and everything on z/OS is >>absolutely OK, except for USS. >>USS still thinks we're three hours East. >> >>Is IPL required anyway (which I don't believe is necessary), or am I missing >>something obvious ? >> >>Regards, >>Giliad >> >>On Thu, 25 Oct 2018 02:39:41 -0500, Giliad Wilf wrote: >> >>>Good question. >>>Developers here do not rely on local time, but I want them to always see >>>local time. >>>It has something to do with human perception of "reality". >>> >>>Giliad >>> >>>On Wed, 24 Oct 2018 16:30:24 -0500, Paul Gilmartin >>>wrote: >>> >>>>On Wed, 24 Oct 2018 02:38:39 -0500, Giliad Wilf wrote: >>>>> >>>>>At 2AM on Sunday, Oct. 28th, Israel is switching from IDT to IST. >>>>>... >>>>>... We ... as far as I know, do not rely on local time. >>>>> >>>>??? >>>> >>>>If you "do not rely on local time", how can timezones and offsets matter to >>>>you? >>>> >>>>-- 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: We're IST-2IDT, and switching back from UTC+3 to UTC+2 at 2AM Oct. 28th
Yes, I did set TZ to IST-2IDT five months ago on /etc/profile, and at additional places , such as: /etc/init.options /etc/httpd.envvars /etc/csh.login /usr/local/zoneinfo ...and, of course, also on CEEDOPT, CEECOPT, and on CELQDOPT sectors of CEEPRM00...to no avail. Something is still missing. I can't believe an IPL is required for USS to pick timezone switch back. On Sun, 28 Oct 2018 08:45:17 +, Gadi Ben-Avi wrote: >For USS stuff, look in /etc/profile. There might be a TZ varable being set >there. > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Giliad Wilf >Sent: Sunday, October 28, 2018 10:26 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: We're IST-2IDT, and switching back from UTC+3 to UTC+2 at 2AM >Oct. 28th > >Well, something did not work as I expected. >(My original post: >https://listserv.ua.edu/cgi-bin/wa?A2=ind1810&L=IBM-MAIN&O=D&P=420113 ) > >The command... >$TA STTZ,T=98.00,'$VS,''SET TIMEZONE=E.02.00''' >...issued on Wed. Oct. 24th did switch local time back from IDT (UTC+3) to IST >(UTC+2) this morning at 2AM (local time switched back to 1AM), and I've >corrected TIMEZONE statement at CLOCK00 to read "E.02.00.00" rather than >"E.03.00.00", but USS still thinks we're on IDT. > >Here are some USS commands I've issued this morning (I did not change anything >on USS parameters since May): > >IBMUSER:/u/ibmuser: >env >MAIL=/usr/mail/IBMUSER >_BPX_TERMPATH=OMVS >PATH=/Z22D/opt/SP/bin:/Z22D/opt/GIT/bin:/bin:. >SHELL=/bin/sh >PS1=$LOGNAME:$PWD: > >COLUMNS=134 >_=/bin/env >LOGNAME=IBMUSER >STEPLIB=none >LANG=C >LIBPATH=/lib:/usr/lib:. >TERM=dumb >HOME=/u/ibmuser >LINES=62 >TZ=IST-2IDT >MANPATH=/usr/man/%L >NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat >TR_Options=noResumableTrapHandler >IBMUSER:/u/ibmuser: >date >Sun Oct 28 10:56:09 IDT 2018 >IBMUSER:/u/ibmuser: >date -u >Sun Oct 28 07:56:18 GMT 2018 >IBMUSER:/u/ibmuser: > > >=End of Display = > >UTC is correct, and one can see 'TZ=IST-2IDT', and everything on z/OS is >absolutely OK, except for USS. >USS still thinks we're three hours East. > >Is IPL required anyway (which I don't believe is necessary), or am I missing >something obvious ? > >Regards, >Giliad > >On Thu, 25 Oct 2018 02:39:41 -0500, Giliad Wilf wrote: > >>Good question. >>Developers here do not rely on local time, but I want them to always see >>local time. >>It has something to do with human perception of "reality". >> >>Giliad >> >>On Wed, 24 Oct 2018 16:30:24 -0500, Paul Gilmartin >>wrote: >> >>>On Wed, 24 Oct 2018 02:38:39 -0500, Giliad Wilf wrote: >>>> >>>>At 2AM on Sunday, Oct. 28th, Israel is switching from IDT to IST. >>>>... >>>>... We ... as far as I know, do not rely on local time. >>>> >>>??? >>> >>>If you "do not rely on local time", how can timezones and offsets matter to >>>you? >>> >>>-- gil >>> >>>-- >>>For IBM-MAIN subscribe / signoff / archive access instructions, send >>>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >>-- >>For IBM-MAIN subscribe / signoff / archive access instructions, send >>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >. >הודעה זו נשלחה אליך מטעם חברה בקבוצת מלם תים וייתכן שהיא מוגנת תחת סודיות >מסחרית. כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי >מורשה החתימה של החברה. החברה רשאית לנטר כל תכתובת העוברת בשרתיה והיא לא תישא >באחריות לכל נזק, ו/או אובדן, שיבוש או פגיעה במידע כלשהו שנגרם מסיבות של תקיפה >חיצונית ו/או זדונית על הארגון. > >-- >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: We're IST-2IDT, and switching back from UTC+3 to UTC+2 at 2AM Oct. 28th
Well, something did not work as I expected. (My original post: https://listserv.ua.edu/cgi-bin/wa?A2=ind1810&L=IBM-MAIN&O=D&P=420113 ) The command... $TA STTZ,T=98.00,'$VS,''SET TIMEZONE=E.02.00''' ...issued on Wed. Oct. 24th did switch local time back from IDT (UTC+3) to IST (UTC+2) this morning at 2AM (local time switched back to 1AM), and I've corrected TIMEZONE statement at CLOCK00 to read "E.02.00.00" rather than "E.03.00.00", but USS still thinks we're on IDT. Here are some USS commands I've issued this morning (I did not change anything on USS parameters since May): IBMUSER:/u/ibmuser: >env MAIL=/usr/mail/IBMUSER _BPX_TERMPATH=OMVS PATH=/Z22D/opt/SP/bin:/Z22D/opt/GIT/bin:/bin:. SHELL=/bin/sh PS1=$LOGNAME:$PWD: > COLUMNS=134 _=/bin/env LOGNAME=IBMUSER STEPLIB=none LANG=C LIBPATH=/lib:/usr/lib:. TERM=dumb HOME=/u/ibmuser LINES=62 TZ=IST-2IDT MANPATH=/usr/man/%L NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat TR_Options=noResumableTrapHandler IBMUSER:/u/ibmuser: >date Sun Oct 28 10:56:09 IDT 2018 IBMUSER:/u/ibmuser: >date -u Sun Oct 28 07:56:18 GMT 2018 IBMUSER:/u/ibmuser: > =End of Display = UTC is correct, and one can see 'TZ=IST-2IDT', and everything on z/OS is absolutely OK, except for USS. USS still thinks we're three hours East. Is IPL required anyway (which I don't believe is necessary), or am I missing something obvious ? Regards, Giliad On Thu, 25 Oct 2018 02:39:41 -0500, Giliad Wilf wrote: >Good question. >Developers here do not rely on local time, but I want them to always see local >time. >It has something to do with human perception of "reality". > >Giliad > >On Wed, 24 Oct 2018 16:30:24 -0500, Paul Gilmartin >wrote: > >>On Wed, 24 Oct 2018 02:38:39 -0500, Giliad Wilf wrote: >>> >>>At 2AM on Sunday, Oct. 28th, Israel is switching from IDT to IST. >>>... >>>... We ... as far as I know, do not rely on local time. >>> >>??? >> >>If you "do not rely on local time", how can timezones and offsets matter to >>you? >> >>-- gil >> >>-- >>For IBM-MAIN subscribe / signoff / archive access instructions, >>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
You can't. BDAM does not support DSNTYPE=LARGE. Giliad On Wed, 24 Oct 2018 18:22:04 +, Frank M. Ramaekers wrote: >I'm a z/VM and z/VSE shop, but we do have a z/OS system and someone in IT want >to know if BDAM can be larger than 65535 tracks. Is this limitation per >extent or entire file size. > >From the z/VSE LISTSERV: >I believe it is 65K tracks per extent with a maximum of 255 extents for BDAM, >but I can't find any doc to verify that right now. > >Frank M. Ramaekers Jr. | Systems Programmer | Information Technology | >American Income Life Insurance Company | 254-761-6649 (732-6649) > >-- >This message contains information which is privileged and confidential and is >solely for the use of the intended recipient. If you are not the intended >recipient, be aware that any review, disclosure, copying, distribution, or use >of the contents of this message is strictly prohibited. If you have received >this in error, please destroy it immediately and notify us at >privacy...@torchmarkcorp.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
Re: We're IST-2IDT, and switching back from UTC+3 to UTC+2 at 2AM Oct. 28th
Good question. Developers here do not rely on local time, but I want them to always see local time. It has something to do with human perception of "reality". Giliad On Wed, 24 Oct 2018 16:30:24 -0500, Paul Gilmartin wrote: >On Wed, 24 Oct 2018 02:38:39 -0500, Giliad Wilf wrote: >> >>At 2AM on Sunday, Oct. 28th, Israel is switching from IDT to IST. >>... >>... We ... as far as I know, do not rely on local time. >> >??? > >If you "do not rely on local time", how can timezones and offsets matter to >you? > >-- 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
We're IST-2IDT, and switching back from UTC+3 to UTC+2 at 2AM Oct. 28th
Hi All, At 2AM on Sunday, Oct. 28th, Israel is switching from IDT to IST. I have issued this morning a JES2 Automatic Command on all z/OS instances: $TA STTZ,T=98.00,'$VS,''SET TIMEZONE=E.02.00''' Currently, our CLOCK00 is: TIMEZONE E.03.00.00 SIMETRID 00 ETRMODE NO ETRZONE NO ETRDELTA 10 STPMODE NO STPZONE NO When I show at office Sunday morning 9AM, I will also modify the line "TIMEZONE E.03.00.00" to read "TIMEZONE E.02.00.00". Will this work, assuming no IPL will occur until Sunday morning? Ah, I forgot to mention. We are a zDPT installation, running z/VM 6.4 and several z/OS guests on top, and as far as I know, do not rely on local time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.3 and VOLCOUNT
I'm reading APAR OA46493 at http://www-01.ibm.com/support/docview.wss?uid=isg1OA46493 and it states twice, both for SMS managed datasets (when there's no dataclass-based volcount) and non-SMS managed, in the below wording: "If the volume count is 1 through 5, the system allows 5 volumes. If the volume count is greater than 5, the system allows 5 plus a multiple of 15 volumes". So, you have to specify 6, 21, 36, etc. (up to 255) to be able to write up to 20, 35, 50, etc. volumes, correspondingly... On Wed, 10 Oct 2018 09:19:16 +, Beesley, Paul wrote: >That makes sense. But seemingly that is no longer true with z/OS 2.3 and >VOL=20 means just that... try and use 21 and you get an abend. > >Regards and thanks >Paul > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Vernooij, Kees (ITOPT1) - KLM >Sent: Wednesday, October 10, 2018 10:12 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: z/OS 2.3 and VOLCOUNT > >That is also how I recalled it, but the description of APAR OA46493 mentions a >start value of 6, with additions in blocks of 15. That could explain why 21 >volumes were possible with a volume count of 20. > >Kees. > > >> -Original Message- >> From: IBM Mairframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Giliad Wilf >> Sent: 10 October, 2018 10:48 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: z/OS 2.3 and VOLCOUNT >> >> On Tue, 9 Oct 2018 12:53:45 +, Beesley, Paul >> >> wrote: >> As far as I remember, specifying no volcount at all lets you write up >> to five volumes. >> If you need more - specifying volcount 6 will let you write up to 20 >> volumes, because DFSMS lets you have 5 volumes plus another whole >> multiple of 15 volumes per each "extension". >> So, if you expect 21 volume or more, up to 35 inclusive - you have to >> specify the vocount as 21. >> >> >Did something change with VOLCOUNT parameter handling between z/OS >> >2.1 >> and 2.3? >> >We have a job that uses 21 tapes to backup an application's datasets, >> and has this parameter: VOL=(,RETAIN,,20), >> > >> >Following the upgrade to 2.3 at the weekend, this job failed S837-08, >> indicating it has run out of tape volumes, which is quite correct. >> >However, looking back at the previous runs, they all have used 21 >> tapes. So they should really have abended as well, but all worked ok. >> > >> >Hence, wondering if something has changed in volume count processing, >> or whether there was a bug in 2.1 which was fixed in 2.3. >> >Would appreciate any suggestions before I face the Spanish >> >inquisition >> who are claiming that my upgrade broke their job. >> > >> >Paul >> > >> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.3 and VOLCOUNT
On Tue, 9 Oct 2018 12:53:45 +, Beesley, Paul wrote: As far as I remember, specifying no volcount at all lets you write up to five volumes. If you need more - specifying volcount 6 will let you write up to 20 volumes, because DFSMS lets you have 5 volumes plus another whole multiple of 15 volumes per each "extension". So, if you expect 21 volume or more, up to 35 inclusive - you have to specify the vocount as 21. >Did something change with VOLCOUNT parameter handling between z/OS 2.1 and 2.3? >We have a job that uses 21 tapes to backup an application's datasets, and has >this parameter: VOL=(,RETAIN,,20), > >Following the upgrade to 2.3 at the weekend, this job failed S837-08, >indicating it has run out of tape volumes, which is quite correct. >However, looking back at the previous runs, they all have used 21 tapes. So >they should really have abended as well, but all worked ok. > >Hence, wondering if something has changed in volume count processing, or >whether there was a bug in 2.1 which was fixed in 2.3. >Would appreciate any suggestions before I face the Spanish inquisition who are >claiming that my upgrade broke their job. > >Paul > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any reason to still use SWA=BELOW?
On Mon, 8 Oct 2018 20:37:23 -0400, Tom Conley wrote: I assume you see this while browsing the syslog for events that occurred during system startup for STCs launched prior to JES2 start. This is why JES2 definition for STC jobclass is ignored. These STCs get serviced by Master Scheduler, not by JES2. >Just wondering if there is any reason to still use SWA=BELOW. I'm >seeing this in a JES2 parm member and I'm surprised, since I changed to >SWA=ABOVE ages ago. > >Regards, >Tom Conley > >-- >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: RECEIVE USERMOD IN BINARY
No. GIMUNZIP requires specially built SYSIN. Something like this: //SYSIN DD * OTH, it could be a paxed ESD to be unpaxed by the 'pax -rvf' command run under BPXBATCH. If this guess is right, you should see after unpaxing a job UNZIPJCL or alike that will do GIMUNZIP. On Fri, 21 Sep 2018 08:37:32 -0500, Paul Gilmartin wrote: >On Fri, 21 Sep 2018 16:12:54 +1000, Wayne Bickerdike wrote: > >>GIMUNZIP? >> >No. > >o It's unlikely that a a USERMOD would be delivered in GIMZIP format. > >o GIMUNZIP is roundabout, more steps. RECEIVE FROMNTS is at least > effective, and simpler. > >Could the victim post here the first few lines of the USERMOD as it >appears on the desktop and as it appears on z/OS, and details of the >process, commands and options. > >-- 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: Spam alert: Model9
Got this e-mail too, inspected it with some concerns, but finally opened it. It could prove useful, as the CEO advised my previous employer on performance issues we had, to our satisfaction. This CEO co-authored many IBM publications, both white and red, and was a visiting developer at IBM of some z/OS components. On Fri, 14 Sep 2018 01:06:43 -0400, Arthur wrote: >Out of the blue (no pun intended), I received an e-mail >newsletter digest from Model9 "because you are subscribed >to Marketing Information from Model9". (I note that they >don't say I *did* subscribe, just that I *am* subscribed.) > >This came to the edress I use *only* for IBM Main, so I >expect many of the rest of you will also get it. Even if it >looks like something you'd like, I feel it's important to >make sure spammers don't profit from their spam. > >Also, remember not to unsubscribe from spam; that's how >they know they have a live edress which is worth more to >sell to other spammers. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ÝEXTERNAL¨ Re: Report volumes with IPLText
On Mon, 10 Sep 2018 17:18:42 -0400, Jim Mulder wrote: > A Stand Alone Dump IPL volume will have a data set >named SYS1.PAGEDUMP.Vvolser > >Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. >Poughkeepsie NY > >> > Just write a VTOC scan program looking for a dataset named >SYS1.NUCLEUS. >> > Every volume having SYS1.NUCLEUS is most likely a RESVOL volume... >> >> What about SAD? >> (SAD = Stand Alone Dump in this context) > Yes, I missed Dyck's ending words and overlooked other sorts of self-loading programs' "signatures"... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Report volumes with IPLText
On Mon, 10 Sep 2018 11:07:21 +, Dyck, Lionel B. (RavenTek) wrote: >Good one 😊 > >No - we are taking responsibility for a sister data center and the individuals >who knew where things were have retired without adequate doc. I'm looking to >find which volumes have ipltext - we know of the ones in active use - just >curious about others - looking for sad and possible stand alone edit. > >-- >Lionel B. Dyck (Contractor) < >Mainframe Systems Programmer – RavenTek Solution Partners Just write a VTOC scan program looking for a dataset named SYS1.NUCLEUS. Every volume having SYS1.NUCLEUS is most likely a RESVOL volume... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB
On Fri, 10 Aug 2018 14:04:16 +, Pew, Curtis G wrote: >On Aug 10, 2018, at 8:35 AM, Giliad Wilf ><00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote: >> >> I can't believe $T JOBCLASS commands will affect STCs started before JES2 >> was up, or started by subsystems other than JES2. > >I can’t either. But does the master subsystem support SWA=ABOVE? > > >-- >Pew, Curtis G >curtis@austin.utexas.edu >ITS Systems/Core/Administrative Services > Your idea can be tested. I only need to write a simple IEFUJV that sets SWA=ABOVE and see what does MSG IEFA111I say for all those STCs that showed SWA=BELOW earlier. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB
On Fri, 10 Aug 2018 13:26:00 +, Allan Staller wrote: >Nope. This can only be changed by command. JES2 will remember prior settings >until changed via command. > >$TJOBCLASS(*),SWA=ABOVE >$TJOBCLASS(STC),SWA=ABOVE <- >$TJOBCLASS(TSU),SWA=ABOVE > >It sounds (to me) like someone issue the command previously and reality and >JESPARM have gotten out of sync. > I can't believe $T JOBCLASS commands will affect STCs started before JES2 was up, or started by subsystems other than JES2. >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Giliad Wilf >Sent: Friday, August 10, 2018 8:19 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB > >Hi All, Observing a z/OS 2.3 start-up of a new system, I can see a lot of >these messages,all of which state "SWA=BELOW". >All our JES2 jobclasses specify "SWA=ABOVE, but these messages are issued >forSTCs invoked before JES2 start-up, or for STCs managed by subsystems other >thanJES2. > AFAIK, SWA location can be set by IEFUJV, which is roughly SR 15,15 plus BR > 14 on our vanilla system. Is there a way to control SWA location for such > STCs without writing a site IEFUJV? Maybe a PARMLIB member, such as ALLOCxx? > Regards, > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB
Hi All, Observing a z/OS 2.3 start-up of a new system, I can see a lot of these messages,all of which state "SWA=BELOW". All our JES2 jobclasses specify "SWA=ABOVE, but these messages are issued forSTCs invoked before JES2 start-up, or for STCs managed by subsystems other thanJES2. AFAIK, SWA location can be set by IEFUJV, which is roughly SR 15,15 plus BR 14 on our vanilla system. Is there a way to control SWA location for such STCs without writing a site IEFUJV? Maybe a PARMLIB member, such as ALLOCxx? Regards, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Where do I find a list of world timezones in z/OS USS notation?
On Wed, 25 Apr 2018 02:21:35 -0500, Norbert Friemel wrote: >On Tue, 24 Apr 2018 03:31:15 -0500, Giliad Wilf wrote: > >> >>Here, IDT started Friday, March 23rd, 2am and will end Sunday, October 28th, >>2am, so, if I specify... >> >>IST-2IDT,M3.4.5,M10.5.0 >> > >M3.5.5 in 2019 (and 2024, 2030, ...) (5th Friday) > >Norbert Friemel > Right, thank you, this may have to be modified from time to time. Seems there should have been a more generalized, better convention for specifying back and forth daylight switching. Sigh. Many thanks to all who contributed insights. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where do I find a list of world timezones in z/OS USS notation?
BTW, John, when looking for possible "standard" names for timezones, I ran across the following page... http://www.linuxhowtos.org/manpages/3/newtzset.htm ...that misled me to think there is such a list. On the above page there is a specific example for Israel specifying IST2IDT (no minus sign), but then, this is a Linux "HowTo" site, not a z/OS one. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Where do I find a list of world timezones in z/OS USS notation?
On Tue, 24 Apr 2018 07:37:53 +0200, Peter Hunkeler wrote: >>What is important is the numeric part. > > >... and whether or not there is a text string *after* that numeric part. It is >the trigger to activate the automatic daylight saving time handling. No >string, no DST handling. > > >-- >Peter Hunkeler > Do you refer to the [[startdate[/starttime],enddate[/endtime]] optional portion of the TZ specification at the below URL? https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxa500/bpxa50065.htm Here, IDT started Friday, March 23rd, 2am and will end Sunday, October 28th, 2am, so, if I specify... IST-2IDT,M3.4.5,M10.5.0 ...will this trigger automatic switchback? Will this switchback be limited to the z/OS USS environment, or will this affect z/OS entirely? I've never tried this, and think a "SET TIMEZONE=E.02.00" will be required as well. This needs be tested when the time for a switchback comes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where do I find a list of world timezones in z/OS USS notation?
Thank you John, I thought there must exist a list with 'standard' timezone names, and that "IST" by itself meant UTC+2 to z/OS USS, as I've never fiddled with this parameter before. I consider entering 'IST-2IDT' into CEEPRMxx's ENVAR parameters too. Thanks again -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Where do I find a list of world timezones in z/OS USS notation?
Hi All, I'm configuring a new system in Israel and wish to pick the correct timezone for our location, in terms of z/OS USS. Our system has been built abroad using CST6CDT, and shipped to us in the form of some 32 dumped 3390-9 volume images. Now I wonder whether or not will IST2IDT be accepted by z/OS USS if placed in '/etc/init.options' and '/etc/profile' files. Are there any additional locations to update, aside from CLOCKxx's TIMEZONE parameter, which I'm going to change from 'W.06.00.00' to 'E.02.00.00'? Our z/OS runs on top of z/VM and Linux zPDT app., which show both correct UTC value, but use a TZ that appears to be the equivalent of EST5EDT. I'm not going to meddle with zPDT or with z/VM. Only with z/OS. Any insight will be greatly appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can the CSI info alone produce a final list required for full resolution of researched PTFs?
On Thu, 15 Mar 2018 11:53:09 -0500, Paul Gilmartin wrote: >On Thu, 15 Mar 2018 11:28:57 -0500, Giliad Wilf wrote: >> >>Normally, the process of resolving all REQ/PREREQ/IFREQ requirements for >>given PTF(s) and collecting all missing items that prevent resolution, up to >>the point where APPLY CHECK suggests that actual APPLY could be successful >>could require several iterations. >> >>Is there a shorter path to resolving all requirements other than ship the >>contents of your CSI to a support center for analysis and preparing a list of >>all requirements? >> >Of course the information is in the CSI. > >APPLY CHECK GROUPEXTEND . > >... and read the reports produced. > >-- gil > I have used GROUPEXTEND since being introduced and can't recall ever being successful in attaining full resolution with one pull. It always took several pulls (iterations) to attain a full resolution. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Can the CSI info alone produce a final list required for full resolution of researched PTFs?
Hi All, Normally, the process of resolving all REQ/PREREQ/IFREQ requirements for given PTF(s) and collecting all missing items that prevent resolution, up to the point where APPLY CHECK suggests that actual APPLY could be successful could require several iterations. Is there a shorter path to resolving all requirements other than ship the contents of your CSI to a support center for analysis and preparing a list of all requirements? I'm not talking about IBM software. It is about maintenance of another vendor's software. People here at our shop think all the information required for a full resolution is already in the CSI and only needs to be gleaned and analyzed in order to prepare a final list of missing items, while I think otherwise and maintain that the CSI alone does not contain all the info required for compiling such a list. You have to have access to a repository style IBM's Enhanced HOLDDATA, which this vendor does not have, you have to pull and receive HOLDDATA, and you might still have to iterate several times before full resolution is attained. Who is right? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support for Doc for COBOL
Yes, but no PDSE may be listed in LPALSTxx, and since LPALSTxx must list SYS1.LPALIB, it can't be a PDSE. On Thu, 14 Sep 2017 07:13:38 -0500, Tom Marchant wrote: >On Thu, 14 Sep 2017 13:02:54 +0200, Peter Hunkeler wrote: > >>The LPA is built as part of the IPL process, but only load modules >>not programs objects can be loaded into PLA at that time because >>program objects live in PDS/Es. > >The LPA statement in PROGxx is processed at the end of IPL. >PDSEs can be included at that time. > >https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/proglpa.htm > >This is a recurring complaint about PDSEs, but I don't see the merit >in it. MVS has provided a mechanism to include program objects when >it is IPLed. > >-- >Tom Marchant > >-- >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: Reload nucleus module dynamically
Maybe the code to be replaced is just a vendor's type 1, 2, or 6 SVC routine in the range 255 to 200. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GDG +1 dynamic allocation collision between two concurrent jobs
The behaviour I recall seeing in batch environment is that when a new GDG dataset is being created, GDG base is being ENQ'ed exclusively. For any other job attempting creation of another dataset per the same GDG base - this base must be *IMMEDIATELY* available, or the second request will be failed on some JCL error, not being waited upon for base availability. I think I've seen something like "DATA SET RESERVATION UNSUCCESSFUL", or alike. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Doc Buddy V2 – Connecting with IBM Z users through mobile
Alas, it requires iOS 9.0 or later, which I don't have (my iPhone 4 runs iOS 7.1.2)... On Sun, 10 Sep 2017 06:57:36 -0500, Parwez Hamid wrote: >For those who are interested, IBM has released V2. The reviews for the earlier >version mixed. Hopefully V2 is an improvement. > >This IBM mobile application that enables IBM to connect with its IBM Z users >in real time. With this latest release of the app, users can search product >messages, read the best-selected technical content about IBM Z products. > >More than 4000 downloads, including 1000 new downloads in the past 15 days >from Google Play and Apple App Store. In the future, more features will be >added to engage users, encourage users to co-create content, and interact with >each other. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lack of Support for Doc for COBOL
On Fri, 8 Sep 2017 13:57:53 +0800, Timothy Sipples wrote: >IBM first introduced PDSEs about 27 years ago. IBM first introduced Java on >OS/390 about 21 years ago. > >That's a long, long time ago. > >It's impossible to defend stubborn opposition to these and to other highly >mature technologies. Business (and the business of government) will get >done, with or without you. If that's how you choose to (mis)behave, then I >can't criticize managers who decide to chuck you in the garbage heap of >history. If you won't change, then you should be/will be changed. I suppose >we can quibble about how much change makes business sense in particular >contexts, but zero is the wrong answer. > >Jimmy Iovine said it well: "Never stop being of service." > Still, the idea that safe, regulated sharing of a PDSE can only be guaranteed to members of a single sysplex, seems to hint that IBM thought at time that no one will ever need more than one sysplex. Doesn't it seem so? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
A closing note: The binder has four entry points: IEWBLINK, IEWBLOAD, IEWBLODI (the one I had trouble with), and IEWBLDGO. Of these four, only IEWBLINK binds into a program library. The other three do perform in-core binding. Yet, the "z/OS V2R2 MVS Program Management: Advanced Facilities" manual states on page 27 that "IEWBLDGO cannot be used for programs containing deferred load classes". Nowhere could I find any such restriction on IEWBLOAD or on IEWBLODI. So, seems the manual has to be corrected and list IEWBLOAD and IEWBLODI together with IEWBLDGO as having this same restriction. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On Fri, 11 Aug 2017 15:59:08 -0700, Tom Ross wrote: > >>Everyone talks about WSOPT vs NOWSOPT compiler option, but I can't find the= >>m documented in COBOL documentation library. >>Are WSOPT and NOWSOPT some nicknames of the accurate terms? >>Where are they documented? > >Everyone? No one should talk about this hidden option. We added it to V5 >for a specific customer situatation. We did not want to change V5 behavior >for everyone. COBOL V6 is now using the preferred WSOPT behavior. That >means that WORKING-STORAGE is acquired from HEAP just like all COBOL versions >did before COBOL V5. This in turn means that the STORAGE option can again be >used to set initial values of WOKRING-STORAGE to x'00' or x'FF' or anything. > >We have improved the "How to find WORKING-STORAGE at runtime" instructions >in the COBOL V6.2 Migration Guide. This has been a work in progress, starting >with trying to do things the 'C' way (WSA) and then moving back to having the >runtime allocate WORKING-STORAGE as in previous COBOL versions. > >By the way, COBOL V5 goes out of marketing in Sept, it will no longer be >available. Honestly, the only COBOL version I would think anyone would want >is COBOL V6.2, it has lots of things to make it more natural for COBOL >application programmers, as well as exploitation of z14 hardware and >performance improvements! > >Cheers, >TomR >> COBOL is the Language of the Future! << > The one thing that confused me was the word "option" which I've looked for in vain at COBOL Customization Guides for V5.1, V5.2 and V6.1. I understood "option" to refer to the selection of one of several possible values a variable can have, at the user discretion, while a "characteristic" would refer to a setting the user has no control over. So, WSOPT seems to a characteristic, not an "option". Are you hinting that Ent. COBOL V6 for z/OS will not generate deferred data classes? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On Wed, 9 Aug 2017 22:18:51 +, Frank Swarbrick wrote: > >There was a post to ibm-main by Allan Kielstra of IBM compiler development (I >think) on May 10, 2017 (How are Program Object sections with Defer attribute >loaded?) that discusses how the writable static area (WSA) is used in COBOL V5 >and COBOL V6. Briefly, this is how I understand it. If the "NOWSOPT" >compiler option is used (the default in COBOL V5) then all COBOL >working-storage is placed in the WSA. If the "WSOPT" compiler option is used >then working-storage is separately allocated upon initial entry to the program >and the address of the WS is placed in the WSA. > >Hopefully I got that all right! > Thank you. I went to Allan Kielstra's post on May 10, 2017, at: https://listserv.ua.edu/cgi-bin/wa?A2=ind1705&L=ibm-main&T=0&O=D&F=&S=&X=C4E3EF984A2A600693&Y=giliadw%40yahoo.com&P=266764 ...and got the info I was looking for. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On Thu, 10 Aug 2017 08:05:04 -0400, Peter Relson wrote: > >I'd have actually said that there is nowhere known to IEWBLODI for the >deferred classes to be >loaded *to* (rather than *from*). It is LE that needs the instantiation of >the C_WSA deferred class. >And LE might need more than one of them, depending on the application. > >IBM would almost certainly decline to support deferred classes in these >services and would decline to provide an option like the one mentioned. > >But I share the question asked in one of the posts about a steplib. >Wouldn't it make more sense to have the test versions of these modules in >a different steplib, with the same module names and not do anything >strange at run-time? Is it not feasible to have the JCL accommodate this? > >Peter Relson >z/OS Core Technology Design > I've been assigned to investigate why a client's home-written debugging monitor that was last modified in the nineties, lacking adequate documentation, and using absolute decimal self-defining terms rather than symbols, started failing when the shop moved to Ent. COBOL V5 for z/OS, from Ent. COBOL V4.2. It turned that the monitor calls IEWBLODI for an in-code re-bind of temp- -named production subroutines and presents them to Contents supervisor in their real names, so that main programs will not need to be changed. I thought maybe there is some compile option that will suppress creation of deferred data classes. I will have to work around this call for IEWBLODI. Thank you. Where can I read about WSOPT/NOWSOPT? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On Wed, 9 Aug 2017 22:18:51 +, Frank Swarbrick wrote: >There was a post to ibm-main by Allan Kielstra of IBM compiler development (I >think) on May 10, 2017 (How are Program Object sections with Defer attribute >loaded?) that discusses how the writable static area (WSA) is used in COBOL V5 >and COBOL V6. Briefly, this is how I understand it. If the "NOWSOPT" >compiler option is used (the default in COBOL V5) then all COBOL >working-storage is placed in the WSA. If the "WSOPT" compiler option is used >then working-storage is separately allocated upon initial entry to the program >and the address of the WS is placed in the WSA. > >Hopefully I got that all right! > Everyone talks about WSOPT vs NOWSOPT compiler option, but I can't find them documented in COBOL documentation library. Are WSOPT and NOWSOPT some nicknames of the accurate terms? Where are they documented? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On Wed, 9 Aug 2017 13:37:54 -0400, Tony Harminc wrote: > >And the resulting IEW2678S makes sense in that context, because there >is nowhere known to IEWBLODI for the deferred classes to be loaded >from. So asking IBM to support deferred classes in IEWBLODI (or >IEWBLOAD, which is the same thing except without the IDENTIFY), makes >little sense. What might make sense would be an option on these two >functions to force all deferred classes to be loaded at the same time >as the non-deferred ones. > >And of course as John M points out, building the PO in a temporary >dataset (or one or more UNIX files...?) would be about as easy, would >perform almost as well, and sounds as though it would accomplish >what's needed. > >Tony H. > Can you suggest why, and what for, does Ent. COBOL V5.1 for z/OS generate deferred data class(es) at all? Is this being controlled by some compiler option that can be negated? Obviously, Ent. COBOL V4.2 for z/OS does not do this. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On Wed, 9 Aug 2017 06:41:04 -0500, John McKown wrote: >I'm probably not really understanding what you want to do. So I'll give a >try at an alternate explanation for what I _think_ you want. You have a >"test" version of a program, call it TESTPGM, in your production PDSE. This >is a test version of PRODPGM in the same PDSE. You have another program, >MAINPGM, which invokes PRODPGM. You want MAINPGM to invoke TESTPGM instead, >without any changes to MAINPGM. You are running MAINPGM inside some sort of >debugger. You debugger can "dynamically rename" TESTPGM to PRODPGM by using >the IEWBLODI. I am wondering why you can't simply do a LOAD on TESTPGM, >then use and IDENTIFY to create a CDE for the name PRODPGM using the EPA >for TESTPGM which you can get from the LOAD. Something akin to: > > LOAD EPLOC=NEWNAME > ST 0,NEWEPA SAME ENTRY POINT > LR 1,0 LOAD EPA TO GPR1 > IDENTIFY EPLOC=OLDNAME,ENTRY=(1) > >Note, that I'm going mainly off of memory, so please excuse any errors in >the above. > >-- >Veni, Vidi, VISA: I came, I saw, I did a little shopping. > >Maranatha! <>< >John McKown You got it right. I need to further analyze the source to find out what else was IEWBLODI supposed to do there. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MSGIEW2678S Module contains one or more deferred classes
apologies All. Sorry for the "dense" post. Here is a re-send: Hi All, I'm trying to do an in-core re-bind of a program object currently residing in a PDSE, rename it, and present its new name to Contents Supervisor, by dynamically calling IEWBLODI to do the job. IEWBLODI fails, issuing MSGIEW2678S, stating "MODULE CONTAINS DATA CLASSES NOT SUPPORTED BY THE LOAD FUNCTION", and further explaining "Module contains one or more deferred classes". This program object has been generated by Enterprise COBOL V5.1 for z/OS. The problem does not occur when the same source gets compiled by Enterprise COBOL V4.2 for z/OS. Close inspection and comparison of the outputs of two compilers, V4.2 vs. V5.1, reveals that COBOL V4.2 generates program objects V2, while COBOL V5.1 generates program objects V3, that obviously contain some deferred data classe(s). I've tried to enforce 'COMPAT=PM2' on the binder at step LKED of the procedure IGYWCL that called COBOL V5.1 to produce the initial program object, to no avail. The binder rejects this override and terminates with RC12. Deferred classes are described as some performance measure intended for postponing costly instantiation, until they are really required. This in-core re-bind for renaming, is part of a home-written debug monitor, intended to allow shop users to do maintenance on production COBOL subroutines, place them under some temporary name in production PDSEs, and renaming them in-core into their "production" names before invoking main programs that call them, so that these main programs will be able to call the subroutines by their "production" names (without having to change anything in the calling main programs). OS is z/OS V2R2. Any advice will be greatly appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MSGIEW2678S Module contains one or more deferred classes
Hi All, I'm trying to do an in-core re-bind of a program object currently residing in a PDSE, rename it, and present its new name to Contents Supervisor, by dynamically calling IEWBLODI to do the job. IEWBLODI fails, issuing MSGIEW2678S, stating "MODULE CONTAINS DATA CLASSES NOT SUPPORTED BY THE LOAD FUNCTION", and further explaining "Module contains one or more deferred classes". This program object has been generated by Enterprise COBOL V5.1 for z/OS.The problem does not occur when the same source gets compiled by Enterprise COBOL V4.2 for z/OS. Close inspection and comparison of the outputs of two compilers, V4.2 vs. V5.1, reveals that COBOL V4.2 generates program objects V2, while COBOL V5.1 generates program objects V3, that obviously contain some deferred data classe(s). I've tried to enforce 'COMPAT=PM2' on the binder at step LKED of the procedure IGYWCL that called COBOL V5.1 to produce the initial program object, to no avail. The binder rejects this override and terminates with RC12. Deferred classes are described as some performance measure intended for postponing costly instantiation, until it is really required. This in-core re-bind for renaming, is part of a home-written debug monitor, intended to allow shop users to do maintenance on production COBOL subroutines, place them under some temporary name in production PDSEs, and renaming them in-core into their "production" names before invoking main programs that call them, so that these main programs will be able to call the subroutines by their "production" names (without having to change anything in the calling main programs). OS is z/OS V2R2. Any advice will be greatly appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEC026I - 637-BC
On Sun, 6 Aug 2017 10:34:42 -0700, Sri h Kolusu wrote: >> Can somebody shed light on this issue - in simple terms please :) ? > >Theo, > >It would be best to avoid concatenation with referback due to the >potential problems caused by the system restriction described here in the >second bullet: > >https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.icem100/beaware.htm > >Be aware that, in some cases, if a DD statement specifies a data set for >output that is extended to a second or subsequent volume, and another DD >statement within the same step requests the same data set, only the >records on the first volume will be read, and incorrect output will >result. > >We always recommend to use one temp data set with disposition MOD . i.e > >//TEMP1 DD DSN=&&TEMP1,UNIT=SYSDA,DISP=(MOD >,PASS),SPACE=(CYL,(X,Y),RLSE) > >Copy your datasets into a single dataset with MOD disposition and you will >not run into the system restriction. > >I am guessing that you are using SPLICE operator to find the matching >records between 2 files IN1 and IN2. Please note that JOINKEYS is much >more efficient technique and it can even handle MANY to MANY match which >SPLICE operator cannot handle. > >Since I don't have your entire TOOLIN Cards I cannot rewrite your JCL. If >you can send your TOOLIN statements then I can optimize the job or convert >it to use JOINKEYS. > >Further if you have any questions please let me know > Since I do not know this tool you are using or what it will do, it >might be possible to use something like SORT to do what you want. > >Lizette, > >The Job is indeed using ICETOOL > > >Thanks, >Kolusu >DFSORT Development >IBM Corporation > You're right. Because the CONCAT DDs are referencing new TEMP1 and TEMP2 in the same step - they will not see any additional volume that TEMP1 and TEMP2 will overflow into. The updated volume information will not be available to the CONCAT DDs. Hence the S637-BC, which says "The last known volume for the data set could not be located while reading a multivolume DASD data set" for the CONCAT DD. This is stated in the JCL Ref. manual, discussing the VOL=REF=*.ddname parameter (same step). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE dataset rename issue
On Mon, 19 Jun 2017 15:23:12 -0500, Tom Marchant wrote: >On Mon, 19 Jun 2017 14:45:13 -0500, Giliad Wilf wrote: > >>On Sun, 18 Jun 2017 20:15:50 -0400, Jim Mulder wrote: >> >>> SETPROG LNKLST,UNALLOCATE >>> >>> SETPROG LNKLST,ALLOCATE >>> >>> Use with caution. >>> . . >> >>The user says he already did this, to no avail. > >It is not clear to me what the OP did. His description of the steps > that he took were not precise, and were scattered among several >posts. > . . On the post opening this specific thread, venkat kulkarni said: "But this dataset was allocated to LLA and XCF. So, we unallocated to linklist and stop LLA". This suggests he did just that, i.e., "SETPROG LNKLST,UNALLOCATE"... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE dataset rename issue
On Sun, 18 Jun 2017 20:15:50 -0400, Jim Mulder wrote: > SETPROG LNKLST,UNALLOCATE > > SETPROG LNKLST,ALLOCATE > > Use with caution. > >Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. >Poughkeepsie NY > The user says he already did this, to no avail. But here is something I saw in the past for MSGIEC614I RC8 on RENAME: User was attempting to RENAME a dataset covered by a generic RACF profile to a name not covered by a generic RACF profile. The discussion there said RACF will not allow this since it would allow the user to unprotect the dataset. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE dataset rename issue
On Sat, 17 Jun 2017 10:45:25 +0300, venkat kulkarni wrote: >Hello Group, >We have requirement to add new SYS1.SIEKLNKE dataset into system. But this >dataset was allocated to LLA and XCF. So, we unallocated to linklist and >stop LLA. After this, we tried renaming this dataset using ispf 3.4 to .old >but system didnt allowed and received below error. > > >IEC614I rename failed rc 08 diagnostic information 040B0426, 914 > >I am unable to find any authentication issue or any other causing this >problem. > >Can you please help. > Are you sure it was SYS1.SIEKLNKE? I can't recall ever seeing SYS1.SIEKLNKE. However, there is a PDSE named SYS1.SIEALNKE, and it is always on the linklist, together with SYS1.LINKLIB, SYS1.MIGLIB, SYS1.CSSLIB, and SYS1.SIEAMIGE, right after SYS1.CSSLIB, even if you did not specify any of them. So, maybe these five special datasets are sort of "pinned" for the life of the IPL, and the only way to fiddle with them is by including corresponding SYSLIB statements for them in PROGxx... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: What is subsystem function code No. 39 and what does it do?
On Wed, 11 Jan 2017 11:05:35 +0100, Roland Schiradin wrote: >SYS1.MODGEN(IEFSSAG) is the related macro for this function code. HTH > Thank you. This macro only describes a layout of an extension to the SSOB for the service requested. Yet, the "Using the Subsystem Interface" manual neither lists this function with services you can request, nor does it list it with services you can provide when writing your own subsystem. Is there any discussion per function code No. 39 somewhere? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
What is subsystem function code No. 39 and what does it do?
It is being described as "Alloc group subsystem requests", but the "Using the Subsystem Interface" manual, SA38-0679, does not say a word about it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Here comes an extra second
On Fri, 30 Dec 2016 08:50:36 -0600, Edward Gould wrote: >https://www.sciencedaily.com/releases/2016/12/161228213356.htm > >On December 31, 2016, a "leap second" will be added to the world's clocks at >23 hours, 59 minutes and 59 seconds Coordinated Universal Time (UTC). This >corresponds to 6:59:59 pm Eastern Standard Time, when the extra second will be >inserted at the U.S. Naval Observatory's Master Clock Facility in Washington, >DC. > Since a leap second is introduced for closing the gap between UTC and TAI, it should be added everywhere around the globe, at the same moment it occurred in Greenwich, England, at Zulu Time, or else clocks around the globe will not be synchronised properly. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How set CVTLSO?
On Wed, 2 Nov 2016 16:03:10 -0500, George Kozakos wrote: . >The "epoch" on z/OS systems is 1900. > . Right. It corresponds to a zeroed TOD. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How set CVTLSO?
On Tue, 1 Nov 2016 15:25:28 -0400, Tony Harminc wrote: . > >Sure - I understand what's going on. It's just that, typically, one >can "see" the nature of the units involved in such a statement. Often >enough, when some politician or news reporter makes a statement like >"Ontario exported 2.5 GW of electricity last year", or "an electric >kettle uses about 1.5 kWh", the meaninglessness jumps right out >because the units make no sense in the context. > >And in the familiar case where the numerator is in a length unit (say, >m), and the denominator in a time unit (say, s), we have names for >each level: distance, speed, acceleration, jerk. > >In this case we have time/time/time, which just fails to jump out at >me. Maybe my imagination, visual or otherwise, is lacking. > . The unit is 1/sec, or Hz. The value is ~ 5.134753814886006906326E-18. . > >Not any computer systems I work with. They use either 1900 or 1970 as >their epoch. What uses 1972? > . If you use leap seconds, then you should see the figure 26 on some HMC STP panel on your z machine, if your epoch is 1972. If you see 36, then your epoch is 1957. I know of no other epoch. Look at page 83 (not the 83rd page but where page footing reads 83) on the below publication: http://www.redbooks.ibm.com/redbooks/pdfs/sg247281.pdf In figure 3-5 there, you can see that leap second count or offset is 25. The manual was printed June 2013 when the count relative to 1972 was 25. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How set CVTLSO?
On Tue, 1 Nov 2016 13:03:27 -0400, Tony Harminc wrote: . > >I'm a little confused about what kind of units "1.4 milliseconds a day >per century" would be in. > >Tony H. > This means that every 100 years, the day gets about 1.4 thousandths of a second longer, compared to the length of the day measured the moment atomic clocks became available commercially, at 1957, and since then, 36 leap seconds were counted. The epoch being used in computer systems is 1972, with 26 leap seconds counted since then. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How set CVTLSO?
On Mon, 31 Oct 2016 10:37:14 -0500, Paul Gilmartin wrote: . >Similarly, when Daylight Saving Time ends (next week) we "add" ond hour >to our civil time clocks in the sense that that day will be 25 hours long >rather than the ordinary 24, by replicating the hour [01:00,02:00). Yet >z/OS chooses to subtract one hour from CVTLDTO. > . I did not mention CVTLDTO because it only affects local time, and most z/OS major subsystems or components, such as JES2, XCF, GRS, DB2, LOGR, CICS (current versions), IMS (current versions) log events using UTC time, not local time. Other major subsystems or components, such as RMF, use local time and may show duplicate time-stamped recordings or one hour gap due to applying DST. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How set CVTLSO?
On Tue, 11 Oct 2016 12:59:47 -0500, Paul Gilmartin wrote: . > >It's not clear why the convention is to add CVTLDTO to ETOD but subtract >CVTLSO... > . Why do we have to add CVTLDTO (which could be negative if East of GMT), but subtract CVTLSO? Because CVTLSO represents by how much TAI is greater than Earth time, and ETS probably feeds you TAI values. Atomic clock ticks at an absolutely constant rate of some 9192631770 oscillations per second (Cesium-133 atom oscillating between two energy ground levels), while Earth sidereal day gets slower(*) by 1.4 milliseconds a day per century. This lagging behind accumulates over time and mounts to almost a complete second over approx. 500 days. As earth rotates and midnight is about to be reached, observatories might notice that the correct position of a fixed point on earth, in relation to very distant stars, is still far away due to the slowing of earth, and midnight must be "postponed" a bit to let earth catch up with distant stars. When this is about to happen (once in approximately 500 days), we have to "add" one second to earth clocks, to "postpone" midnight. Postponement of midnight is attained by stepping earth clock from 23:59:59 through 23:59:60, to 00:00:00, rather than the normal sequence 23:59:59 to 00:00:00. Internally, CVTLSO is increased by one and the accumulated sum is subtracted from the TAI fed from ETS. As I've said, TAI is greater than Earth time by the accumulated leap seconds (a negative leap second is possible in principle, but has not been observed so far). Below you can find animation of two clocks. The upper is TAI (the atomic clock). The lower is earth clock. The difference at this moment is 36 (relative to 1957, but only 26 relative to 1972, which is an alternative epoch on some systems). https://www.timeanddate.com/time/leap-seconds-background.html (*) Why does earth slow down? This slowing down is caused because earth is not a rigid body. Rather, it has liquid core, has tectonic plates floating and drifting astray, or being shifted during earthquakes, is covered by seas and oceans that undergo cyclic high and low tides, which convey some of earth's angular momentum to the moon, which in turn gets further away from earth at a rate of 1.5 inch a year. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol Install FS issue
On Thu, 10 Mar 2016 12:47:58 +0530, Mainframe Mainframe
wrote:
>Hello Group,
> While installing Cobol 5.2, I am getting below issue.
>
>BPXF140E RETURN CODE 0081, REASON CODE 0594003D. A LINK FAILED FOR
>LINK NAME /Service/usr/lpp/cobol/../../demo/oosample/Check.j
>
>I did check for all directory path and I don't find any issues with this. I
>checked all available solution but nothing working for me.
>
>Any clue.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
- In order to maintain two different versions of Enterprise Cobol
simultaneously, there is a requirement that each version
has to have its own SIGYROOT filesystem.
- When there is only a single version of Enterprise Cobol, its SIGYROOT gets
mounted at '/usr/lpp/cobol/'.
- What do we do if we have two or more?
- The answer is you define two different mountpoints on top of
'/usr/lpp/cobol/' and mount each Cobol's SIGYROOT at its own
unique mountpoint.
- Each Cobol will look for the DDDEF for SIGYHFS, which ends with
'.../bin/IBM/', back two directory levels, and will expect
its own SIGYROOT to have been mounted there, and will expect to see
directories 'demo', 'include', and 'lib' alongside
directory 'bin'.
- Lookup the internet for a description of a technical problem, using
"igzcjava.x" and BPXF140E as search arguments,
e.g. http://www-01.ibm.com/support/docview.wss?uid=swg21195928
We were installing Enterprise Cobol V4R2 for z/OS alongside existing Enterprise
Cobol V3R4 for z/OS, and what I did was this:
unmount filesystem('V3R4.SIGYROOT') immediate
mkdir '/usr/lpp/cobol/EC34' mode(7,5,5)
mkdir '/usr/lpp/cobol/EC42' mode(7,5,5)
mount FILESYSTEM('V3R4.SIGYROOT') MOUNTPOINT('/usr/lpp/cobol/EC34')
TYPE(HFS) MODE(RDWR)
mount FILESYSTEM('V4R2.SIGYROOT') MOUNTPOINT('/usr/lpp/cobol/EC42')
TYPE(HFS) MODE(RDWR)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Boundaries of the 64-bit LocalSystemArea
Apologies for the blundered format of my earlier post. Here is a re-send. Page 459 of the publication http://www.redbooks.ibm.com/redbooks/pdfs/sg247946.pdf on paragraph "21.1.2 Local system area" says: === Quote === Note: A keyword has been added to the IARV64 REQUEST=GETSTOR, LOCALSYSAREA=NO|YES, to indicate that the memory object is to be allocated from the system area of the 64-bit address space map. LOCALSYSAREA memory objects are allocated in the system area that starts at X’8_’ - 32 GB and ends at X’28_’ - 288 GB. Only authorized users may use this keyword. === End of quote === ...however, 288G is x'48_', not x'28_’, or am I missing something? Another question: Are these boundary lines of the LocalSystemArea sort of "fixed by architecture", or need they (at least the high end) be looked up in some control block? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The boundaries of the 64-bit LocalSystemArea
Page 459 of the publication http://www.redbooks.ibm.com/redbooks/pdfs/sg247946.pdf on paragraph "21.1.2 Local system area" says:=== Quote ===Note: A keyword has been added to the IARV64 REQUEST=GETSTOR, LOCALSYSAREA=NO|YES, to indicate that the memory object is to be allocated from the system area of the 64-bit address space map. LOCALSYSAREA memory objects are allocated in the system area that starts atX’8_’ - 32 GB and ends at X’28_’ - 288 GB. Only authorized users may use this keyword.=== End of quote === ...however, 288G is x'48_', not x'28_’, or am I missing something? Another question: Are these boundary lines of the LocalSystemArea sort of "fixed by architecture", or need they (at least the high end) be looked up in some control block? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RE-IPL for the Daylight to Standard time conversion?
Much to my regret I've seen the discussion on topic "RE-IPL for the Daylight to Standard time conversion?" too late, and was unable to read all posts on the issue, so bear with me if it turns out that someone else has already mentioned an excellent publication I'm mentioning now: SG24-2070 - S/390 Time Management and IBM 9037 Sysplex Timer, at http://www.redbooks.ibm.com/redbooks/pdfs/sg242070.pdf Chapter 9, "Offset Change Impacts to Subsystems", is worth reading (and so is Chapter 8). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
How much CPU percentage can be expected to be reclaimed?
We are having four partitions defined on one of our boxes (2086), with one z/OS image always running, one CF LPAR with CFCC always running, but the remaining two idle most of the time (that is, the remaining two partitions are active and have their share of resources allocated, but no OS is running there). All CPs are shared. None dedicated. We wonder what percentage of CPU, otherwise spent on PR/SM management, could be spared and reclaimed if: (1) We run a single z/OS image in Basic mode on this 2086 (no LPARs defined)? (2) We inactivate the two partitions that are usualy idle and redistribute their resources. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
