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
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
of
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 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 was
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
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
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
the
| 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
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
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 face
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.
The cells are mentioned in United States Patent US4680653. That
appears to be one of the patents that
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 services
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
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
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 WAS
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
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
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 programs
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
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 not
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
file;
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 change
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
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 158
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,
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 was
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:
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
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
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
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 time.
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
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 to
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
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 William
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 the
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
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.
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 should
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 June
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 to
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
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 the
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
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. But
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
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
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
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
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, in
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
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
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
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
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
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
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 disappear
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
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
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
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
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.
IBM
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
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 in
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 believe HASP II Version 4.
Really? I suppose I'll have
... 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 record
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
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:
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 Scheduler
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 be
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),FILTER
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
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 you.
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
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:
|
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 string ptr
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 post
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 memories
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 the
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 [obvious]
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
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 in
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'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 a
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.
(but the
1 - 100 of 101 matches
Mail list logo
