Abe F. Kornelis noted:
> I have all but completed the updates of the opcode tables on hlasm.com
> There's a peculiarity I'd like to discuss here.
I have discovered some additional ones.
After adding all the new zWhateverR mnemonics to my SPF/SE color tables,
SPF/SE complained about duplicate wor
Charles Mills asked:
| A PDSE can hold program objects that are effortlessly
| converted to conventional load modules when you copy
| them to a PDS. How's that?
IEBCOPY invokes the Program Binder to do the conversion. For example:
> IEB1135I IEBCOPY FMID HDZ1A10 SERVICE LEVEL NONE
Tom Kelman complains:
> Yea, I tried the user ID and password I use for all other
> accesses to IBM and it won't accept it. When I try to
> reregister with my email address it says it's already in
> use. What gives?
I don't know, but I had the same problem, so I called the phone number (one
Shmuel Metz asked:
> Does anybody still have the issue of Datamation coining the term "nybble"?
What have you heard or what do you know about that story?
--
WB
--
For IBM-MAIN subscribe / signoff / archive access instructions,
Rick Fochtman wisely noted:
| Stupidity is always a reason and often an excuse.
| Unfortunately, there's no vaccine for it.
It would not matter if there were a vaccine. I am convinced that
by the time a child is old enough to be vaccinated the disease has
already taken firm hold, and the un
Rick Fochtman said:
> Peter, I suspect it's a carry-over from the days
> when DISP=OLD did reserves on shared DASD.
> I may be wrong.
Shmuel (Seymour J.) Metz said:
| > I may be wrong.
| You are. DADSM does a reserve. Various applications do RESERVE. But
allocation does not.
If that statement
John Chase remembers:
> ISTR that "PDF" (now ISPF option 2) was the full-screen editor;
> an add-on to "SPF".
The full-screen editor, formerly called SPF (the "Structured
Programming Facility") was incorporated into ISPF (renamed by
then, twice, to "Interactive System Productivity Facility") as
J R notes:
> Maybe I'm misremembering but I'm sure I was using SPF, not ISPF,
> in or around 1974 -- and that *was* developed within IBM.
Yes. SPF was developed by IBM and used internally for a couple of
years before it was released as a program product in 1976. Tom
Simpson and Dr. Mark Mergen
| >Because ISPF is 1980s technology?
|
| ITYM 1970's.
It would, in fact, be 1976, to be specific about it.
--
WB
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the mes
Alan Starr wondered:
> I have no idea why there is a limit of 59 volumes per dataset.
That's 59 units (that is, UCBs or devices), which, for DASD data
sets translates to 59 volumes. There is no such limitation for
TAPE data sets, of course, since a tape drive can be reused for
subsequent volumes
> What was the design objective of IEBGENER, anyway?
Design objective? In 1965? They didn't have design objectives for utility
programs then -- other than, perhaps, to run in 20KB (on a 32KB 360/30). How
can a useless program have design objectives? It's already useless.
You do know that utilit
Seymour J. Metz asks:
> I need a reference for Wikipedia as to whether the cells on a 3380
> only relate to error checking or whether they actually reflect the
> physical layout of the track.
The "cells" are mentioned in United States Patent US4680653. That
appears to be one of the patents that
Seymour J. Metz asks:
> I need a reference for Wikipedia as to whether the cells on a 3380
> only relate to error checking or whether they actually reflect the
> physical layout of the track.
I have found it. And, now that I have found it, I remember it. This
getting old is for the birds!
Seymour J. Metz asks:
> I need a reference for Wikipedia as to whether the cells on a
> 3380 only relate to error checking or whether they actually
> reflect the physical layout of the track.
I've never seen this documented. But I never looked that deeply,
either, so it might have been in my fa
Ted MacNEIL started this latest sub-discussion within this thread with:
> I was one of the ones, in Canada, complaining about the constant
> changes in geometry. 3330->3350->3380->3390 (and don't forget
> 'compatability' mode.
Seymour J. Metz responded to Ted:
> Because you didn't use system ser
Paul Gilmartin retorts:
> I see "never been any consideration" as a failure of the
> designers to step back and ask themselves, "What will be
> the customers' perception of this behavior?"
> The resource deficiency, then, appears to have been in the
> designers' perspective.
That might be a
Paul Gilmartin offered the following:
> Well documented; inexcusably counterintuitive. I suspect the
> historical rationale is that 40+ years ago allocation couldn't
> muster the resources to perform a STOW to delete a member when
> the allocation had the form above.
Nope. There W
Shmuel Metz (Seymour J.) offered:
> IEFZGST1 and IEFZGST2 anyone?
Nah ... both of those at least had comments (line AND block).
--
WB
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send em
Old Man (like me) Bill Fairchild noted:
> you were supposedly able to configure a model 30 with only 8K.
True, and IBM took a boatload of first-day orders for 8KB 360/30
boxes. Before any of them shipped, it was clear that nothing at
all useful could be done with them. I don't know if
Brian Peterson asked:
> Maybe someone ... on this list more familiar with the oddities
> of OS/360, could ... explain what DEALLOC is/was intended to
> accomplish.
Simply ensure that "Allocation" got control. Only Allocation
would actually (for example) vary a DASD volume offline. To
make it ha
Edward E Jaffe wonders:
> ... "old" programs with many hard-coded offsets and lengths
> ... why [was this] such common practice back then[?]
Younger and newer programmers followed the habits of those
who came before them. Many of those who first ventured into
"OS" extensions and "neat, useful pro
Tom P Hylton suggested:
> The enterprise systems automation list still receives traffic.
>
> List:automat...@protechpts.com
>
> Subscribe To:list...@protechpts.com
> Subscribe Text: "join automation" (in body of document)
That didn't work (the "listman" e-mail account is
Tom Conley notes:
> I've never seen this issue with Vista. Did you report it to Tom
> and send him the corrupted .ses file?
When I initially saw it repeatedly, yes, I did. Tom wrote me that
it was an unusual [but not unprecedented] problem, the ".ses" file
was clobbered, he had no clue how it
Miklos Szigetvari asked:
> For a PC the Vista large screen size is not working ... for all
> other PC's it is o.k and for this PC it was still yesterday o.k.
I have seen this before; in fact, I see it about every 2-3 months.
The solution is to delete the involved (selected/specified) ".ses"
fil
Shmuel Metz explains:
>> I know one got put in there, but I didn't know it got put
>> there because some customer(?) asked for it to be put in.
>
> My recollection is that IBM created the eyecatcher APAR
> without customer input.
I just remember it showing up, but figured it was just a
release
Edward Jaffe notes:
> As I stated, I've seen it done far more than I ever expected.
The problem, Ed, is that you expect (or at least hope for) mostly
rational behavior, and you view such mechanisms as irrational and
odd (because there are better, more appropriate, ways to do this).
While I acad
Bruce Richardson asked:
> ... sure your code didn't suffer the same fate as IEFBR14?
Yes. The entire routine needed two base registers. But that
would not have mattered anyway: IEFACTRT was loaded in LPA.
Our friend Shmuel (Seymour J.) Metz contributed this to us:
> Bruce Richardson said:
>
>
John McKown stated:
> So, to be able to track the relationship between an MVT job
> and a HASP job, the name of the job while executing had to
> be unique.
No. There was no confusion. HASP knew quite well which JOB was
running in an initiator (that is, under a certain task). The
real problem w
Rick Fochtman wrote:
> Consider chewing gum and bailing wire?? :-)
An old war story is always fun, ne c'est pas?
I've told this one before here, but it is right up
this little side alley Ed Jaffee started. This one
involves a missing hammer.
I had standalone time on a 360/75 one weekend, fr
Dennis Roach relates his very interesting experience:
> ... had a 3031. We added the AP to it. ... The problem did not
> occur with the AP offline. ... There was an optional EC that
> reduced a section of tri-lead by 18 inches. The EC fixed the
> problem.
Lynn Wheeler notes:
> remember that 15
Edward Jaffe asks:
> Which is the best IEFACTRT?
I am dying to know what you meant exactly by that question.
But I'll offer my candidate (in case this is a contest):
IEFACTRT CSECT
IEFACTRT AMODE 31
IEFACTRT RMODE ANY
R1 EQU 1
R14 EQU 14
R15 EQU 15
SRR1,R1
"A clear violation of the principle of least astonishment" was a
phrase first used in my presence by Jim Doody (then) of Marine
Midland Bank at a GUIDE meeting in 1975. It was obvious what it
meant, but I cornered him afterwards to ask him about it.
He did not claim originality. It stuck in my
Paul Gilmartin asked:
> So I wonder why the scheme chosen was not the last 4
> digits of +8900. It would have matched the chosen
> scheme for the 20th and 21st centuries, and provided for
> smooth extension to the 19th and earlier.
Nobody was expecting to run into any SMF records with
dates
Andy Wood wonders:
> Maybe they were just optimists and figured that by the
> time they really needed it, the operating system would
> have been updated to provide it.
As I said, I don't know where Poughkeepsie got the idea.
Maybe they thought of it all by themselves. We did not
care at the tim
John Chase reminded us:
> EIBDATE is, and has been long enough to be "forever", a four
> byte packed-decimal field. From SDFHMAC:
>
> EIBDATE DSPL4 DATE IN 0CYYDDD+ FORMAT,
> * where C is the century
> *
Timothy Sipples suggests:
> How about Gerrit Blaauw?
I second that. The descriptions on that list are, at best,
amusing. For example, it identifies Gene Amdahl as "the
chief architect of the System/360," which was definitely
not the case. That honor belongs to Gerrit A. Blaauw. In
considerat
> which were opened for the system/360 project
The East Fishkill, NY plant was specially built to manufacture
Solid Logic Technology (SLT) modules for the System/360. At the
time, this plant was considered "highly automated." I am not
aware of any plants in the U.S. that were specifically built t
> how to obtain current TCB address in an assembly pgm.
USING PSA,0 PSA addressability
L R3,PSATOLD -> Current TCB
USING TCB,R3 TCB addressability
...
IHAPSA LIST=NOPSA DSECT
IKJTCB LIST=NO
Peter Relson wondered:
> I can't remember if that also requires supervisor state
Actually not (or at least it did not used to). Normally, one does
not run in key 0 problem state, but it's fairly easy to get into
that state with an APF-authorized job step and the MODESET macro.
At one point in a t
William Blair wrote:
> Until the binder API can function
> as a full-fledged system service, it can't be used by any
> code that, itself, has to adhere to long-established MVS
> integrity and authority guidelines.
That could have been better worded, as follows:
Until t
Leona Baumgart stated:
> If LE is not available
Uh ... since LE is part of the BCP, how, exactly, would it ever
be "not available?" I am not disputing that there is, perhaps,
some test that the binder code makes, but I cannot imagine what
that test is.
> will re-contact both Chris and Willia
> Were your discussions with "STL" done before or after
> "Metal-C" became available?
Yes: before AND after. I had to examine my archives and files
to answer your question. They took place around these dates:
Most weeks every month during:
o February through August 2001
o March through
Brendan Friel asks:
> 1) Has it always been a farce ?
Yes. At least since 1974.
> 2) Are there lots of other scenarios where it doesn't
>work ?
Yes. Several have been elucidated here, already.
> 3) What is exactly is the root cause of this farcical
>behavior ? The DISP=SH example sho
Paul Gilmartin asks:
> In what language is the binder written?
As far as I know, PL/X. But the binder itself is not actually
the problem. It's the C/C++ / LE-dependent routines that the
binder [API] invokes; they are the cause of the entanglements
that the binder [API] suffers from, apparently. A
Tom Conley offered this:
> You should only be allowed to complain after your PMR is closed
> WAD.
Been there, done that, got the T-shirt. That's what started the
various (and ultimately not fruitful) technical dialogs with STL.
We actually had two of them. Another customer was involved the
se
Bill Klein reminds us:
> ... but I *do* repeat that unless/until the SHARE
> requirement process is "tried" for such things, it
> seems wrong to me to assume that it will NEVER work.
No "assumptions" are involved. A higher authority has
already been appealed to. IBM STL was, itself, at one
point
Dave Day expressed his genuine surprise (how novel!)
regarding the behavior of the Binder API, thusly:
> I did not expect these entries to be in the buffer
> in non ascending order. I'll change my code to
> check and place them in the internal map in correct
> order, but this sure seems broke
Doug Henry wrote:
> It is not often (maybe never) that I get a chance to correct you.
That's twice in one day. Earlier today, Edward Jaffe of Phoenix
Software corrected me on a small detail about JES3 buffer virtual
storage locations.
I have an excuse for JES3, since (as you well know) I'm not
Abe Kornelis wondered:
> I guess it does make a difference when redirecting
> spooled output to a DASD or tape dataset?
> Experience says it does make (a lot of) difference
> in that case - but I may be outdated on that one.
Well ... since I have this handy-dandy little test
program, I changed t
Thomas Berg wrote:
> Interesting. I see that You used FA. What would the result
> be with V/VB ?
Identical. See the results in the table where I did that (for
the smaller record sizes). Blocking the output INCREASES the
per-line CPU overhead (for the reasons I speculated).
> I suppose the cp
gah wrote:
> How do you do the timing?
tused = Task_CPU_used_AFTER - Task_CPU_used_BEFORE
> Does it include all CPU cycles used by the user
> program, JES2, SVC handlers, etc.?
Yes, everything that MVS charges to the task CPU timer.
So, in a nutshell, the answer to your question is: YES.
>
Thomas Berg wrote:
> ... [performance] consideration ... dcb for a SYSOUT dataset.
> ... I want to write multiple lines on sysout and they are of
> very different lengths, everything from zero to 3 chars.
> Does it matter if I use FB or VB and what [LRECL] i use ... ?
Yes, it could matter. B
Gerhard Postpischil wrote:
> The first version of IEFBR14 did not clear R15, making for
> interesting condition code test results in subsequent steps.
You have a great memory.
Ed Finnell wrote:
> IIRC there were APARs to BR14.
There were five or six just after it first shipped. Then
they bot
Your PARM field is too long to fit on one card:
// PARM='SH echo sftp -b /u/bpxbatch/mccheckftp
// fis-depot-test.ucdavis.edu |su -s bpxbtch'
The rules of continuation for the PARM field would ostensibly
require that you specify it as follows (that is, the correct
syntax
Shmuel Metz (Seymour J.) wrote:
> One a leased train wouldn't they be under contractual
> obligation to replace the worn slugs at their expense.
Yes. Several popular characters on ours were repeatedly
being replaced. IBM suggested some slug graphic combos
that would result in them having to rep
Kirk Wolf asked:
> ... updating a member with statistics is expensive since
> it would probably have to rewrite the whole directory to
> expand the directory entry length.
Not necessarily. Regardless, don't worry about it. It is
not an issue if the data is a PDSE. If it is an ordinary
PDS, it
Jack Kelly wrote:
> I joined the list but never have been able to search it.
I had the same problem, but I found it went away as soon
as I established a ListServ password for the server (not
the JES2-L list). It works for all lists on that server,
but I didn't find any other lists that interest
Ted MacNEIL wrote:
> JES2-L is moribund!
One wouldn't think so at first: the list has 448 subscribers
(now 449, with the recent addition of myself). But the last
message was November 7, 2007 so you appear to be correct.
Activity on the lust had slacked off considerably prior to
that, so it
Jeff Holst noted that an IBM SRL states:
> 1. Overriding statements can appear in any order when
>they explicitly specify the step that is being
>overridden.
This is apparently the "missing" documentation. However,
it is not completely technically correct, because it is
obviously not, i
Shmuel (Seymour J.) Pedantic Metz offered us some
of his acclaimed wisdom and experience by stating:
> Would that that were true.
> I was never at a shop where they were rented,
First: What time period are you referring to, here?
Interesting. Both of my (very old) copies of the green
book do n
Tony Harminc wrote:
> Do you mean an algorithm? ... I'm not sure there is an overall
> algorithm, though obviously there are certain patterns to be
> seen.
Of course there is an algorithm. Card readers implement it. In
fact, it can be deduced (or reverse engineered) simply by use
of Boolean al
Dave Gibney wrote:
> Folks relying in //SYSIN DD * GENERATED STATEMENT are getting
> what they deserve. :)
You didn't read everything I wrote. This has nothing to do with
the automatically-generated //SYSIN DD * statement. Explicit DD
statements are being reordered. What is happening happens lo
Barbara Nitz wrote:
> the 3 disappearing ones are purged from another system
> than the 17 that arrive in ESF.
I still think it would be a good idea to define the output
DD statement (for the data set whose output "disappears")
so as to send it to multiple destinations, and resubmit
all 20 (or w
Barbara Nitz wrote:
> the 3 disappearing ones are purged from another system
> than the 17 that arrive in ESF.
Are those three perhaps running a different release of JES2?
Are the JES2 INIT parameters "identical" for all members?
--
WB
-
John Mattson wrote:
> Somewhere between OS390 2.10 (our old system) and zos 1.08 (our
> new system) the JCL interpreter changed.
Funny you should notice that ... was wondering if anybody would.
The change was first introduced in z/OS 1.8. It worked the old way
in z/OS 1.7. When I first found th
Barbara Nitz asked:
> //SYSTSPRT DD SYSOUT=H,LRECL=256,RECFM=V,DEST=R720
What are the (default) characteristics of SYSOUT CLASS H?
Anything special, or different than whatever the MSGCLASS
of the JOB is?
> He noticed that *some* of the output 'disappears',
Is the output that does NOT disappea
Is there anybody listening here whose subscription email address
is [EMAIL PROTECTED] ? If so, please pay close attention.
John McKown wrote:
> I'm getting duplicate emails from the list. Is anyone else
> or am I just lucky?
I have been getting duplicate emails from IBM-MAIN, off and
on, for se
Martin Kline wrote:
| //BUILD EXEC PGM=IEBGENER
| //SYSUT1 DD *
| RECORD 1 PLUS SOME EXTRANEOUS CHARACTERS > 40
| RECORD 2 PLUS SOME EXTRANEOUS CHARACTERS > 40
| RECORD 3 PLUS SOME EXTRANEOUS CHARACTERS > 40
Eric Bielefeld wrote:
> Really? I always thought the 3380s and 3390s were CKD device also
Yes, really. Seymour J is right, as hard as that might be to believe.
These drives are, under the covers, really FBA devices. Externally,
however, they are CKD devices (because you use the standard CKD C
Paul Gilmartin wrote:
> I'm surprised at a factor of 5. Wouldn't doubling the
> gamut of characters result in half as many copies of
> each on the train, and no worse than halve the throughput.
You have made an unwarranted assumption. A TN print train
did not merely add 26 lower case alphabetic
> it's available in Format1 DSCB.
>
> TMDS1FLAG1,DS1COMPR
> JORETBUFNO
Greg Price wrote:
| Ripper. You know, I looked there but obviously missed it.
| I guess it's OBTAIN time.
Not necessary. You can examine the DSCB in the DCB exit, which
has the additional advantage that you can exa
Paul Gilmartin wrote:
> I had imagined the TMP interposed its own filter behind BSAM/QSAM.
> Educate me: How, outside the TMP, can one code a call to BSAM or
> QSAM to perform folding? Is there something line DCB=(OPTCD=FOLD)?
You can't. No, there isn't. OPEN device-dependent code itself will
d
Paul Gilmartin asked:
> And why are terminal data sets ("DSN(*)") converted to
> upper case, no matter what I do?
and then provided an example of _data_ contained in a
terminal data set being folded to upper case.
Well, WHY is for the same reason I previously stated:
because TSO was written, in
Paul Gilmartin wrote:
> //STEP EXEC PGM='FooBar'
> IEFC629I INCORRECT USE OF APOSTROPHE IN THE PGM FIELD
>
> Why?
Because the code does not support, and therefore does not
expect, a quoted string as the value of the PGM= operand
on an EXEC statement. But I suspect you already knew that.
I
Hans Visser asked:
> How can i determine in an assembler program whether
> a dataset is allocated on dasd or vio?
There are many ways to skin this cat. We'll start with the
simple way. If that's not appropriate, we can get into the
more esoteric ways later.
I'll first assume that the data set i
Shmuel (Seymour J.) Metz wrote:
> In ... on 05/22/2008 at 02:46 PM,
> "William H. Blair" <[EMAIL PROTECTED]> said:
>
> >I had made mods to HASP 4.0 for SVS
> >(OS/VS2 Release 1.7) to support this transparently.
>
> There was no HASP 4; I might bel
> ... could you not just use RECFM=V and send
> 84 byte JCL and 208/212 LRECL SYSIN Data?
I assume so, but I never tried to do that. Using in-stream
data sets with more than 80 bytes per card was an extension
to an existing program (that used to require only 80 bytes
of in-stream data) which used
> Was this with RECFM=F or RECFM=V?
The "SYSIN" input data set was read (by the program that
was executed by the JCL submitted via the INTRDR) with a
DCB that specified RECFM=VB,LRECL=252,BLKSIZE=256. It
used the LOCATE form of the GET macro, so it just looked
at the RDW to see how long a recor
> Speaking of "80-column", when did JES2 overcome the
> fixed 80 restriction on SYSIN data sets?
The short version: (1) Long ago for LRECL up to 254.
(2) z/OS 1.7 for LRECL up to 32K. The long version:
We had an application that read LRECL=204 or 208 or
something like that in JES2 4.1. Note:
Chris Mason wrote:
> ... the enhancements to the 3270 data stream which came in
> with the 3279 - back in 1979 wasn't it? -
The 3279 color display station models 2 and 3 and the 3287
color printer were announced on October 2, 1979. The GDDM
programming support for PS graphics would not be avai
> By 1979 360/75s were 10+ years old.
By 1979, 360/75s were 13-14 years old. TUCC in RTP, NC got one of
the very first early in 1966. I was told in 1967 by one of the CEs
in residence at TUCC that it wasn't the first one out of the barn,
but it was nearly so. We knew that NASA had ordered five,
Bob Lester wrote:
> Do you know if the 360/75 was a common machine at the time?
> I worked as an operator on a 360/75J (and a 360/30).
The System/360 Model 75 was not an UNcommon machine (as were
the Models 91, 95, 85 and 195) but it was not exactly common.
Only VERY large shops would feel the
Distinguished IBMers that might be lurking,
(especially of the CATALOG ADDRESS SPACE-knowledgeable variety)
On Wed, 21 Mar 2001 15:55, Mark Thomen <[EMAIL PROTECTED]> wrote:
> THIS RESTRICTION HAS NOT BEEN REMOVED! Until CAS is "full function",
> which doesn't occur until after Master Schedule
David W. O'Brien wrote:
> So a Linear dataset will have a Cisize that is a
> multiple of 4096, not an absolute value of 4096.
You are correct. I was assuming that nobody had (and
the original poster had NOT) done anything really
inappropriate. For any CISIZE past 16KB you get into
diminishing r
Hans Visser wrote:
> Walt,
>
> i don't think you're right.
>
> he is looping from the end of the buffer to the beginning.
>
> SRCHLOOP CRR7,R8start of buffer reached?
>BEFINALyes, exit
>CLC 0(R9,R8),FILT
Arthur T. wrote
> You don't mention the CI size.
He does not need to. Gilbert Cardenas wrote:
>LINEAR -
which means that it will have a CISIZE of 4 KB (4096).
There are exactly 180 4K blocks (CIs) in each 3390 CYL.
All LINEAR cluster space allocation calculations can b
Edward E Jaffe wrote:
> I presume the reason is that an ICF engine has more
> moving parts and precision components forged from
> precious metals -- requiring higher manufacturing
> costs. These costs are passed on to the consumer in
> the form of higher prices... :-D ;-) O:-)
Ed, I've met y
Paul Gilmartin wrote:
> Is there somewhere a customer who has an esthetic dislike for
> "SYS1" and uses an alternative HLQ for production data sets?
I promise you, they are all over the place. If we could somehow
gather all IBM z/OS customers together in one place (like SHARE)
and then arrange th
In the past week or so I had written that most of the System/360
architects (or, to paraphrase another, "brilliant lights in a
sea of bright lights") were still around. Sadly, ~46 years after
they started working together (on what would become System/360
and OS/360), we have been reminded that they
Art Celestini wrote:
> I'm convinced that TRE and TR are faster but it seems that
> a truly "fair" comparison of solutions to the stated problem
> should have included equivalent moves in the TRE and TR
> solutions.
I did write and run versions with the code like that. And, I
said so:
|
Kirk Wolf said:
> I'm looking for the fastest way in assembler to
> translate data in one buffer to another using a
> 256-byte translate table.
Want my test program to help you decide? Let me know.
But don't waste your time. I already know the answer.
Look at my TR subroutine in a previous pos
Edward Jaffe wrote:
> The following fragment should work if you prefer looping
> TRE over traditional TR. TRE requires you to manually
> translate the so-called "stop" character with an MVC.
> But, at least there's no EXecute for the final segment.
>
> LM R14,R15,xx Load strin
Mark Zelden wrote:
> Seems like a good idea. Has a requirement ever been submitted?
> If not, someone should.
Yes. Many times. The issue was dealt with (that is, dispensed
with) in the GUIDE "JES Job Scheduling and Control" Task Force
report. Unfortunately, that was a long time ago, and memorie
Paul Gilmartin wrote:
> I would prefer that ZONE be an argument to STCKCONV so any
> user anywhere could convert a timestamp, possibly recorded
> elsewhere, to local time. Even better, ZONE should support
> values indicating specific, not necessarily local, time zones.
Yes, that was an [obvio
Paul Gilmartin wrote:
> Yes, but the important distinction is that, in contrast
> to the CVT fields, neither TZ nor any other environmental
> setting needs to be changed semiannualy.
True. But I bet most z/OS mainframe folks are happy it still
works the way it does now. Why? Not everybody wants
Edward E Jaffe wrote:
> You don't "fall back" from CST. You "spring forward" to CDT,
> which is -0500!
Correct. And, springing forward from -8 (PST) yields -7 (PDT),
which was the actual time zone offset of the system on which I
executed the demo program:
> I was confused about the time zone on
Paul Gilmartin wrote:
> As I see it:
>
> The service corresponding to time() is TIME STCK[E],,ZONE=GMT
Except for the difference in epoch and radix, the UNIX time()
function is conceptually equivalent to z/OS "TIME STCK[E],addr"
or "TIME BIN,addr,ZONE=GMT" or "TIME DEC,addr,ZONE=GMT".
> (
Paul Gilmartin wrote:
> I'm confused. I thought STCKCONV takes as input a TOD
> clock value, and if you operate as IBM recommends, TOD
> clock values are always GMT.
STCKCONV takes a TOD clock-FORMAT value as input. What that is,
or what that input represents, is YOUR business. STCKCONV is
just
Barry A Schwarz wrote:
> Is CDT really 7 hours off from GMT?
No. I was confused about the time zone on the machine on which I
tested the code. I have access to systems with various time zone
offsets.
That was really PDT (Pacific Daylight Time), not Central Daylight
Time (CDT) as I stated.
Paul Gilmartin wrote:
> I believe this is in contrast to the z/OS STCKCONV service.
> however, I can not find in the docmentation ("z/OS V1R7.0 MVS
> Assembler Services Reference IAR-XCT") whether STCKCONV
> returns local time or GMT nor how Daylight Saving and Leap
> Seconds are handled (possibly
1 - 100 of 101 matches
Mail list logo
