Re: Xdc output print
Sorry for not following this thread properly. I don't know why OP wants a PDS dataset. Nothing wrong with that; it just puts the user in charge of getting the right attributes. Suggestion: Use XDC to create a brand new sequential dataset with SDSF's preferred attributes. Then use ISPF 3.2 to create a PDS with same DCB attributes. As others have said, let SDB optimize block size. Fastest, cleanest way I can think to do it. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Friday, December 30, 2016 10:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Xdc output print Hello All, Sorry for delay. I think the issue was, somebody defined PDS with record length of only 80 and and then when we were doing XDC and trying to put report into PDS member even by specifying bigger record length but its report was not able to fit because PDS was only defined with 80 length. So, now i created PDS with VBA and bigger record length and all worked.. Thanks for all help. On Fri, Dec 30, 2016 at 3:18 AM, Doug wrote: > Have you tried FBA or VBA ? > Late to the party but typically LRECL plus 1 gets the job done for us. > Regards, Doug > > . > > On Dec 29, 2016, at 15:29, Sri h Kolusu wrote: > > >> If I specify VB, it allows one character (for carriage control?) > regardless, > > thereby possibly truncating the last character of data. > > Paul, > > Just so you know you can issue the SE command to edit your spool and > then you can remove the first byte by shifting to the left ((1 and > then C followed by CREATE command to copy the contents without > the carriage control characters > > Thanks, > Kolusu > > IBM Mainframe Discussion List wrote on > 12/29/2016 01:01:11 PM: > > > From: Paul Gilmartin > > <000433f07816-dmarc-requ...@listserv.ua.edu> > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 12/29/2016 01:02 PM > > Subject: Re: Xdc output print > > Sent by: IBM Mainframe Discussion List > > > >> On 2016-12-29, at 12:12, Gibney, Dave wrote: > >> > >> Stop specifying blksize. For that matter, don't specify LRECL or > > RECFM either, SDSF knows from JES. > >> XDC to a new SEQUENTIAL file. > >> > > Errr... If I omit SPACE, RECFM, or LRECL, SDSF complains about > > Invalid > Value. > > If I specify VB, it allows one character (for carriage control?) > regardless, > > thereby possibly truncating the last character of data. > > > > SDB will handle BLKSIZE. > > > > -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Xdc output print
On 2016-12-31, at 09:54, Jesse 1 Robinson wrote:
> Sorry for not following this thread properly. I don't know why OP wants a PDS
> dataset. Nothing wrong with that; it just puts the user in charge of getting
> the right attributes.
>
> Suggestion: Use XDC to create a brand new sequential dataset with SDSF's
> preferred attributes. Then use ISPF 3.2 to create a PDS with same DCB
> attributes. As others have said, let SDB optimize block size. Fastest,
> cleanest way I can think to do it.
>
But if it's NEW, why go to a PDS at all? Just keep the PS data set.
It ain't clean. Alas, the XDC display, ISFPNO41 seems not to copy
attributes from the spool file. It reports INVALID VALUE and the
user must supply the attributes.
But beware. I vaguely understand that JES2 doesn't use the standard
representation with RDWs and carriage control characters. JES2
(sometimes) believes that LRECL is the data length, excluding the
RDW, and carriage control for each record is indicated outside the
data. (Might it be possible to mix A, M, and none in the same spool
data set? How? Why!?)
For example for my JOB02946 the JDS display shows SYSTSPRT with LRECL=133:
SDSF JOB DATA SET DISPLAY - JOB LONGOUT5 (JOB02946)LINE 10-11 (11)
COMMAND INPUT ===>SCROLL ===> CSR
NP DDNAME StepName RecFM LRecL ProcStep DSID OwnerC Dest
SYSTSPRT SETUPVBA 133 104 User R LOCAL
PF 1=HELP 2=SPLIT 3=END 4=RETURN5=IFIND 6=BOOK
PF 7=UP8=DOWN 9=SWAP 10=LEFT 11=RIGHT12=RETRIEVE
. . . . . . . . . . . . . . . . . . . . . . . . . . .
... but if I browse ("S") the SYSTSPRT and enter the "?" (info?) command,
I see LRECL=137:
Display Filter View Print Options Search Help
---
SDSF OUTPUT DISPLAY LONGOUT5 JOB02946 DSID 104 LINE 0 COLUMNS 02- 81
COMMAND INPUT ===>SCROLL ===> CSR
FORMSFCB UCS WTR FLASH C CPY REC-CNT LRECL CCTL DEST
STD R 1 123 137 ASA LOCAL
... JESMSGLG, however, shows VA,133 for both. Might VBA vs. VA cause the
difference? It shouldn't; both have the same RDW and BDW overhead.
I've learned more than I like to know about this by gathering information
IBM has requested for an SR I have open.
> -Original Message-
> From: venkat kulkarni
> Sent: Friday, December 30, 2016 10:33 PM
>
> Sorry for delay. I think the issue was, somebody defined PDS with record
> length of only 80 and and then when we were doing XDC and trying to put
> report into PDS member even by specifying bigger record length but its report
> was not able to fit because PDS was only defined with 80 length.
>
You're lucky. Too many programmers have corrupted their PDS by doing
this. PDSE may be safer.
-- gil
--
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. > See today's Google Doodle. When will they release the balloons? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Two IEASYSxx
And 00 always gets used.. unless there isn't one. Rob Schramm On Thu, Dec 29, 2016, 8:18 AM Peter Relson wrote: > You can have as many IEASYSxx as you can fit into the LOADxx statement or > the reply to "specify system parameters". > > >the IPLINFO is not showing up > DISPLAY IPLINFO will show the SYSP specification. > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Two IEASYSxx ?
If IPLINFO isn't working.. which would be weird .. my first thought is that you not authorized for command Barring that and other "head slapping" " DOH" (Homer Simpson reference) possibilities... Then it would make me start questioning the system Integrity. D IOS,CONFIG? Rob Schramm On Wed, Dec 28, 2016, 8:27 AM Carmen Vitullo wrote: > Tthat is something similar to a shop I worked in where I had a singe > parmlib library for all lpars in a sysplex > the LOADxx member specified an ieasymxx member > IEASYM (00,L) > then the ieasymxx member, based on the CEC name and LPAR > > SYSDEF HWNAME(CEC1) > LPARNAME(APROD1) > SYSPARM(00,20) /* USE xxx COUPLE MEMBER */ > SYSNAME(SYSA) > SYSCLONE(SA) > name setup the correct IEASYSxx members to be used, only difference in the > specific ieasys member for the lpar was the page dataset names, omvs parms > to useetc > > > OMVS=(00,21,SA), SELECT BPXPRM00,21 AND SA > SMF=&SYSCLONE, > LFAREA=7740M, > PAGE=(PAGE.SYSA.VSYSPG0.PLPA, > PAGE.SYSA.VSYSPG0.COMMON, > PAGE.SYSA.VSYSPG1.LOCAL, > PAGE.SYSA.VSYSPG2.LOCAL, > PAGE.SYSA.VSYSPG3.LOCAL, > PAGE.SYSA.VSYSPG4.LOCAL, > PAGE.SYSA.VSYSPG5.LOCAL, > PAGE.SYSA.VSYSPG6.LOCAL, > PAGE.SYSA.VSYSPG7.LOCAL, > PAGE.SYSA.VSYSPG8.LOCAL, > PAGE.SYSA.VSYSPGH.LOCAL, > PAGE.SYSA.VSYSPGI.LOCAL, > PAGE.SYSA.VSYSPGJ.LOCAL, > PAGE.SYSA.VSYSPGK.LOCAL, > PAGE.SYSA.VSYSPGL.LOCAL, > PAGE.SYSA.VSYSPGM.LOCAL,L) > and for out local DR box a different couple member was used depending on > which 8870 were were IPLing from > hope this makes some sense, its still early for me > > > Carmen > > - Original Message - > > From: "Nathan Astle" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Wednesday, December 28, 2016 2:59:41 AM > Subject: Two IEASYSxx ? > > Hi > > Can we have two IEASYSXX members in an LPAR ? > > Since one of our LPAR has 1 IEASYSxx but it has only page dataset coded and > the LOADxx member too shows the sysparm value which has the IEASYSXX > containing page dataset. > > How do I find the second IEASYSXX member since the IPLINFO is not showing > up > > Nathan > > -- > 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 > -- Rob Schramm -- 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
11:59:60? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, December 31, 2016 10:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Here comes an extra second See today's Google Doodle. When will they release the balloons? -- 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 Sat, 31 Dec 2016 11:53:41 -0800, Charles Mills wrote: >11:59:60? > ITYM 23:59:60. I actually got a Linux system to display 23:59:60 for a carefully chosen TZ and time value. Them guys is thorough. What if your program balks at that value? Well, it's the fault of that program. (I should have posted a link): https://www.google.com/doodles/new-years-eve-2016 -- gil -- 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 Sat, 31 Dec 2016 16:11:48 -0600, Paul Gilmartin wrote: >On Sat, 31 Dec 2016 11:53:41 -0800, Charles Mills wrote: > >>11:59:60? >> >ITYM 23:59:60. It should happen at 00:00:00 in each time-zone. In one timezone that will be 1 second later than in all the others, but still at 00:00:00 :) -- Walt -- 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 Sat, 31 Dec 2016 16:32:04 -0600, Walt Farrell wrote: >>> >>ITYM 23:59:60. > >It should happen at 00:00:00 in each time-zone. In one timezone that will be 1 >second later than in all the others, but still at 00:00:00 :) > I had believed it happened at 23:59:60 UTC regardless of what time zone you're in. So, in America/Denver, 16:59:60. Have you a citation asserting otherwise? (Or we can go back to ASSEMBLER-LIST and discuss the most efficient way to zero a register.) -- gil -- 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 Sat, 31 Dec 2016 16:39:17 -0600, Paul Gilmartin wrote: >On Sat, 31 Dec 2016 16:32:04 -0600, Walt Farrell wrote: >>>ITYM 23:59:60. >> >>It should happen at 00:00:00 in each time-zone. In one timezone that will be >>1 second later than in all the others, but still at 00:00:00 :) >> >I had believed it happened at 23:59:60 UTC regardless of what time zone you're >in. So, in America/Denver, 16:59:60. > >Have you a citation asserting otherwise? The most recent question, I think, and the one I answered, was "when will Google release the balloons". You seem to be answering "when will the leap second occur" :) >(Or we can go back to ASSEMBLER-LIST and discuss the most efficient way to >zero a register.) We could. (Actually, I think that's where the thread on "ASMA032E Relocatable value or unresolved symbol found when absolute value required" should have taken place. That way there would have been more chance that the IBMers who work on the assembler, and know the answer, would have seen it.) -- Walt -- 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 Sat, 31 Dec 2016 18:31:08 -0600, Walt Farrell wrote: >>> >>>It should happen at 00:00:00 in each time-zone. In one timezone that will be >>>1 second later than in all the others, but still at 00:00:00 :) > >The most recent question, I think, and the one I answered, was "when will >Google release the balloons". You seem to be answering "when will the leap >second occur" :) > Ah, I understand. Is that how Google coded it? And that, in turn depends on many variables, such as whether I have enabled geolocation in my device, or where my Internet backbone connection is. (For a couple weeks Google believed I was in India rather than Colorado because my employer was using a fallback proxy.) >>(Or we can go back to ASSEMBLER-LIST and discuss the most efficient way to >>zero a register.) > >We could. (Actually, I think that's where the thread on "ASMA032E Relocatable >value or unresolved symbol found when absolute value required" should have >taken place. That way there would have been more chance that the IBMers who >work on the assembler, and know the answer, would have seen it.) > Lizette wasn't alert. Perhaps for the best; I believe Charles got the right answer, perhaps with better SNR than on ASSEMBLER-LIST. -- gil -- 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
Paul Gilmartin wrote: I had believed it happened at 23:59:60 UTC regardless of what time zone you're in. So, in America/Denver, 16:59:60. We have empirical proof of that at one of my clients . Took down a monitoring system this evening. Was peacefully spawning services and suddenly the last-started time was in the future and it spawned 100 in a second and choked. -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan -- 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 Sat, 31 Dec 2016 20:10:05 -0700, Jack J. Woehr wrote:
>Paul Gilmartin wrote:
>> I had believed it happened at 23:59:60 UTC regardless of what time zone
>> you're
>> in. So, in America/Denver, 16:59:60.
>
>We have empirical proof of that at one of my clients . Took down a monitoring
>system this evening.
>
But that's not what Walt was discussing.
>Was peacefully spawning services and suddenly the last-started time was in the
>future and it spawned 100 in a second and choked.
>
But why? It should perceive it's ahead of the game and take a (short)
coffee break. (" The last started was 23:59:59.98. So I need to start the
next one at 23:59:59.99. But it's only 23:59:59.01, so I can relax.")
Details? What OS? z/OS? Other (specify)?
So it was slavishly following NTP (or other?) which duplicates the 23:59:59
second
because POSIX doesn't allow it to Do the Right Thing and the "monitoring
ssystem"
did no filtering at all on the NTP (whatever) input.
The world ought to adopt a rational (not yet close to standard) accommodation:
https://developers.google.com/time/smear
... and avoid even the milder disturbance such as:
http://members.iinet.net.au/~nathanael/ntpd/leap-second.html
... which would be tough on z/OS, which has committed to a different path.
-- gil
--
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 Sat, 31 Dec 2016 20:10:05 -0700, Jack J. Woehr wrote: > >We have empirical proof of that at one of my clients . Took down a monitoring >system this evening. > >Was peacefully spawning services and suddenly the last-started time was in the >future and it spawned 100 in a second and >choked. > Ah! You could do it with z/OS. It just takes some truly bad coding: When each "service" starts, it fetches CVTLSO; does STCK; adjusts (as TIME macro does) and logs that as the started time. The "monitor" also fetches CVTLSO when it starts and continues to use that frozen value to adjust STCK. So it thinks it's way behind, and each service it starts is still almost a second tardy. It's the cost of the false economy of moving a double-word fetch out of a not-very-tight loop. That's why C invented the "volatile" storage class, but the programmer forgot to declare CVTLSO volatile. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
