PDSE sharing in a SYSPLEX Environment
Kenneth J. Kripke
Current installation standards forbid the use of PDSE's because enqueue's do
not get
broadcast through GRS or MIM, hence, integrity issues. How does a PDSE
serialize at the member level?
What major name does it use to accomplish this?
Kenneth J. Kripke
kcr...@nycap.rr.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Knutson, Sam
Partitioned Data Set Extended (PDSE) Usage Guide
http://www.redbooks.ibm.com/redbooks/pdfs/sg246106.pdf
Chapter 4 covers PDSE sharing and serialization.
IGWSYSZ0 AND IGWSYSZ1 were added for PDSE and must be sysplex wide. I
think you might be headed towards "How can I share PDSE in multiple
SYSPLEX's?" and my limited understanding is that is simply not possible.
I hope that helps.
Best Regards,
Sam Knutson, GEICO
Performance and Availability Management
(office) 301.986.3574
"Think big, act bold, start simple, grow fast..."
Friske, Michael
serialization. Since XCF signaling cannot be done with a system outside
the sysplex, there is no integrity when a system outside the sysplex
updates a PDSE that is being updated by systems within the sysplex.
There is a whole chapter about sharing and serialization in the Redbook
Sam referenced.
-----Original Message-----
From: Kenneth J. Kripke [mailto:kcr...@ibm-main.lst
Sent: Monday, April 26, 2004 5:01 AM
To: IBM-...@BAMA.UA.EDU
Subject: PDSE sharing in a SYSPLEX Environment
Environment is multiple SYSPLEX's using MIM GDIF component.
Current installation standards forbid the use of PDSE's because
enqueue's do
not get
broadcast through GRS or MIM, hence, integrity issues. How does a PDSE
serialize at the member level?
What major name does it use to accomplish this?
Kenneth J. Kripke
Mark Zelden
<kcr...@NYCAP.RR.COM> wrote:
>Environment is multiple SYSPLEX's using MIM GDIF component.
>Current installation standards forbid the use of PDSE's because enqueue's
do
>not get
>broadcast through GRS or MIM, hence, integrity issues. How does a PDSE
>serialize at the member level?
>What major name does it use to accomplish this?
>
>
Search the archives for much discussion on this. We share PDSE
across syspexes, but "read only". We are also a MIM shop. Also
search for some posts from me that will point you to a CA-MIM
document on PDSE sharing available on their web site.
Mark
--
Mark Zelden
Sr. Software and Systems Architect
mailto: mark....@zurichna.com
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
gil...@ibm-main.lst
> Date: Mon, 26 Apr 2004 09:10:36 -0400
>
> For extended sharing, PDSE using XCF signaling and GRS (or MIM) for
> serialization. Since XCF signaling cannot be done with a system outside
> the sysplex, there is no integrity when a system outside the sysplex
> updates a PDSE that is being updated by systems within the sysplex.
>
My experience has been that the update attempt fails with:
IEC143I 213-70,IGG0191B, ...
even when the data set is merely being browsed by another system.
-- gil
--
StorageTek
INFORMATION made POWERFUL
gil...@ibm-main.lst
> Date: Mon, 12 Jan 2004 10:33:36 -0800
>
> gil...@UNIX.STORTEK.COM wrote:
>
> >Concerning your requirement that started this thread, I've
> >done the following in a Rexx EXEC as an experiment toward a
> >no-workfiles approach:
> >
> >o Used "cp" do copy a Classic data set to the input of a pipe.
> >
> >o Used "gzip" to compress the output of that pipe, with the
> > compressed stream going to the input of a second pipe.
> >
> >o Used BPXWDYN to allocate the output of the second pipe to
> > DD(whatever). So far, so bad.
> >
> >o Attempted to use FTP to "PUT //DD:whatever remote.file".
> > This fails with: "EZA2602E Error reading the file". After
> > much experimenting, I can find nothing I'm doing wrong, nor
> > any documented restriction I'm transgressing. EXECIO reads
> > DD:whatever with no error and correct result. So I've
> > opened ETR Item 64765,033,000 on the problem. We'll see
> > whether I get WAD, and how soon.
> >
> >To be continued,
>
> Wow! Thanks! Isn't there an API to z/OS ftp that can be invoked from
> REXX? (I may be thinking of another platform -- aka OS/2.) If so, that
> might provide the makings of a workaround.
>
IBM has supplied APAR AQ83770 which repairs the EZA2602E. I can now
pipe in a Rexx script from an MVS data set through "cp", "gzip" (or
"compress"), then FTP to a remote (well, local Solaris) incoming
directory with no use of local workfiles.
It's ambiguous whether this usage violates an explicit restriction in
IBM's FTP client: FTP is documented as not supporting local character
special files. It does not make it explicit whether this extends to
DDNAMEs allocated to character special files. At the moment it works.
(How does one formulate a Requirement for a construct which happens
to work but is not documented as supported?)
In experimenting I note that DCB attributes on the DD statement
allocating the HFS file are ignored by FTP. I consider this an error.
APARs PQ64224 and PQ54913 addressed similar problems with DDNAMEs
allocated to tapes. The same considerations motivating these two
APARs apply equally to DDNAMEs allocated to HFS files. In particular,
PQ64224 states in the text:
The FTP Client is erroneously using the LOCSITE DCB parameters
for output tape data sets allocated via DDname instead of
honoring the DCB attributes specified on the DD statement.
LOCSITE parameters should never be involved in the open of a
^^^^^^^ ^^^^^^^^^^ ^^^^^^ ^^^^^ ^^ ^^^^^^^^ ^^ ^^^ ^^^^ ^^ ^
data set allocated via DDname.
^^^^ ^^^ ^^^^^^^^^ ^^^ ^^^^^^
I suppose I'll need to raise this issue in a further APAR.
I'll supply the Rexx test code (Not Ready for Prime Time) in a private
communication if desired.
Edward E. Jaffe
>I'll supply the Rexx test code (Not Ready for Prime Time) in a private
>communication if desired.
>
Please do!
--
-----------------------------------------------------------------.
| Edward E. Jaffe | |
| Mgr, Research & Development | edj...@phoenixsoftware.com |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
'-----------------------------------------------------------------'
gil...@ibm-main.lst
> Date: Mon, 17 May 2004 14:38:17 -0500
>
> Chuck DES and go to RSA, which uses both public and private keys. Copy of
> original working paper on request. <G>
>
All this piqued my curiosity. So I looked up:
# 2.1.25 "z/OS V1R2.0 ICSF Application Programmer's Guide"
2.1.25 Random Number Generate (CSNBRNG)
The callable service uses the cryptographic feature to generate a
random number. The foundation for the random number generator is a time
variant input with a very low probability of recycling.
What _does_ that mean? Any of:
O It hashes contents of various system control blocks (time variant,
and not very repetitive)?
O It samples the noise from a hot resistor?
O It hashes packets from SETI@home?
O Other (specify)?
O "If I told you, I'd have to kill you"?
The last seems unlikely; the scheme must at some point be
subject to intense security audits. But those could be NDA.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
gil...@ibm-main.lst
> Date: Wed, 26 May 2004 13:53:55 +0100
>
> can a program start executing even before it is fully loaded into memory. For e
> xample, if program A consists of 10 pages, then does it start execution even if
> only the first 2 pages are loaded in memory ?
>
I believe that if the program resides in Pageable LPA, pages will be
fetched as they are accessed, and execution can begin as soon as the
first page is fetched into main memory.
> I remember some one telling me that while execution of a program a part of the p
> rogram can be in memory and the program is executed by paging etc, but before ex
> ecution it requires the whole program to be loaded in memory. If enough memory n
> ot available to load the whole program then it fails. Is this true and why do yo
> u have to load the whole program before execution ?
>
Address "Constant" relocation probably requires that most pages will
be passed through main memory before execution can begin. However,
under severe storage constraints such as you envision, it's possible
that earlier pages will be swapped out while later pages are being
processed, so it is not necessary that any instant the entire program
be resident in main memory. The failure should not occur. (But is
the program's area page-fixed by CS during this process?)
Are we helping a student with a class assignment? your questions
seem academic?
gil...@ibm-main.lst
> Date: Wed, 26 May 2004 07:54:42 -0700
>
> Yes. This is one of the advantages offered to PDSE program objects
> linked with the NOPRIME option. After the program starts executing,
> unloaded pages of the module are loaded (and have ADCONs resolved etc.)
> via page faults. If an unloaded page of the module is never referenced,
> it is never loaded.
>
Yow! So Page Fault Handler must consult a table to see whether
the page has unresolved RLDs. And update the page. And update
the table.
Worse, if the ADCON is (mis-)aligned to cross a page boundary,
the adjacent page must be loaded in order to propagate carries
from the bottom to top of the ADCON. This is effectively a
page fault triggered deep within the page fault handler.
And if the process has done a fork(), the page is mapped
into two address spaces. Does updating the ADCON mark the
page as dirty and trigger a COW, or does the updated page
remain shared?
I suppose all these cases have been tested and found to work.
This is fun! Should I cross-post to ASSEMBLER-LIST?
Edward E. Jaffe
>I suppose all these cases have been tested and found to work.
>
NOPRIME functionality has been around for as long as program objects
have been supported (MVS/ESA 4.3?). Indeed, since it is a default binder
option, it's likely that nearly every large program object loaded over
the past decade has exercised some aspect of the logic. Nevertheless, I
expect IBM would appreciate any additional testing of pathological
conditions you might be able to render, even at this late date in the
development cycle.
--
-----------------------------------------------------------------
| Edward E. Jaffe | |
| Mgr, Research & Development | edj...@phoenixsoftware.com |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
-----------------------------------------------------------------
----------------------------------------------------------------------
gil...@ibm-main.lst
> Date: Thu, 27 May 2004 08:14:52 -0400
>
> I'm guessing it's a typo that's taken on a life of its own. A Google search
> for EDCDIC turned up only 315 hits (vs. 257000 hits for EBCDIC).
>
These are the hits in IBM doc:
IBM Library Server Shelf search results "z/OS V1R5.0 Collection, March 2004 - z/OS..
Search Results for a Shelf
Search results for shelf: EZ2ZBK05 "z/OS V1R5.0 Collection, March 2004 - z/OS
V1R5.0 elements and features (Discs 1 and 2)"
2 books have matches for: edcdic
[Book] [PDF] IEA2G240 z/OS V1R5.0 MVS System Management Facilities (SMF)
[Book] ZIDOCMST z/OS and z/OS.e DOC APAR and PTF ++HOLD Documentation
_________________________________________________________________________________
There are 0 hits at z/OS V1R2.0. Apparently a recent innovation.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Craddock, Chris
> the page has unresolved RLDs. And update the page. And update
> the table.
From a functional stand-point, yes. But how the magic occurs is
a subject for the BCP folks to divulge (or not.) The pages are DIV
mapped, so I assume DIV is closer to where it really happens than
ASM is, but I am unaware of the details. Jim may enlighten us some.
> Worse, if the ADCON is (mis-)aligned to cross a page boundary,
Can't be. ADCONS are always word aligned and will never "cross"
a page boundary.
> And if the process has done a fork(), the page is mapped
> into two address spaces. Does updating the ADCON mark the
> page as dirty and trigger a COW, or does the updated page
> remain shared?
See point 1 above. Implementation details of fork() and its
cousins are not public and few if any of the "usual suspects"
that would be tempted to dig around and figure it out have
bothered to look. I know I haven't.
> I suppose all these cases have been tested and found to work.
I've mentioned several times in the past that the binder doc
is a work of modern fiction and I've got ETRs to prove it. IBM
has a project in the works at present to ensure that the binder
really does do what the books say it ought to. To the best of
my knowledge the NOPRIME option works exactly as described, but
since I don't have any use for that option I can't swear to it.
Chris
Edward E. Jaffe
>... To the best of
>my knowledge the NOPRIME option works exactly as described, but
>since I don't have any use for that option I can't swear to it.
>
Are you typically specifying PRIME? If not, you are getting NOPRIME by
default.
--
-----------------------------------------------------------------.
| Edward E. Jaffe | |
| Mgr, Research & Development | edj...@phoenixsoftware.com |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
'-----------------------------------------------------------------'
Craddock, Chris
> >... To the best of
> >my knowledge the NOPRIME option works exactly as described, but
> >since I don't have any use for that option I can't swear to it.
>
> Are you typically specifying PRIME? If not, you are getting NOPRIME by
> default.
We specify PRIME explicitly in all of our bind JCL for precisely that
reason. I can't imagine "NOPRIME" working out correctly for a program
object loaded in the common area and referenced by disabled programs.
But perhaps I'm just overly cautious.
Chris
gil...@ibm-main.lst
> Date: Thu, 27 May 2004 10:30:27 -0500
>
> > Worse, if the ADCON is (mis-)aligned to cross a page boundary,
>
> Can't be. ADCONS are always word aligned and will never "cross"
> a page boundary.
>
?????
1 Page 3
Active Usings: None
0 Loc Object Code Addr1 Addr2 Stmt Source Statement HLASM R4.0 2004/05/27 10.48
0000000 00000 01002 1 TEST CSECT
000000 2 DS CL4094''
000FFE 00000000 3 DC AL4(TEST)
001002 4 DS 0C
5 END
?????
Shall we take this thread to ASSEMBLER-LIST?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
john gilmore
> We specify PRIME explicitly in all of our bind JCL for precisely that
> reason. I can't imagine "NOPRIME" working out correctly for a program
> object loaded in the common area and referenced by disabled programs.
> But perhaps I'm just overly cautious.
I use NOPRIME routinely for common-area program objects accessed by programs
that run disabled. These POs are, however, of a special kind. They are
NOTEXECUTABLE table sets some of the elements of which must be and are
loaded on a page boundary (TRTx-instruction use).
Are they/can they be brought into virtual storage while my code is running
disabled? With Chris, I have always assumed not. How the disaster that
would occur if they were not already resident is avoided is not clear
either. Still, the scheme does work, if perhaps only by making NOPRIME moot
in some circumstances.
This experience of course disposes of only some of the nightmare scenarios
Chris may have in mind.
John Gilmore
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
William Ek
I would imagine that even before the days of the binder it
was your practice not to run disabled unless you knew that
any storage you were referencing was fixed; certainly
NOPRIME adds nothing new. Even were the entire program
loaded into storage it could be paged out in the time
between load and reference.
Bill Ek
> FREE pop-up blocking with the new MSN Toolbar - get it
Edward E. Jaffe
> Chris Craddock writes:
>
>> We specify PRIME explicitly in all of our bind JCL for precisely that
>> reason. I can't imagine "NOPRIME" working out correctly for a program
>> object loaded in the common area and referenced by disabled programs.
>> But perhaps I'm just overly cautious.
>
>
> I use NOPRIME routinely for common-area program objects accessed by
> programs
> that run disabled. These POs are, however, of a special kind. They are
> NOTEXECUTABLE table sets some of the elements of which must be and are
> loaded on a page boundary (TRTx-instruction use).
>
> Are they/can they be brought into virtual storage while my code is
> running
> disabled? With Chris, I have always assumed not. How the disaster that
> would occur if they were not already resident is avoided is not clear
> either. Still, the scheme does work, if perhaps only by making
> NOPRIME moot
> in some circumstances.
>
> This experience of course disposes of only some of the nightmare
> scenarios
> Chris may have in mind.
I'm not sure if the common area is really an issue here. NOPRIME is the
default and SETPROG LPA in COMMNDxx is routinely used to add large
program object libraries to the link pack area. It seems reasonable that
page-fault resolution of unloaded pages works just as well for modules
in the common area as for those in the private area.
The real issue seems to be the potential for disablement. This would
present problems regardless of whether the module was loaded into
private or common storage or whether it was bound with NOPRIME or PRIME.
The obvious remedy is page fixing the parts of the module needed by
disabled code. This should be required in all cases.
--
-----------------------------------------------------------------.
| Edward E. Jaffe | |
| Mgr, Research & Development | edj...@phoenixsoftware.com |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
'-----------------------------------------------------------------'
----------------------------------------------------------------------
Ed Gould
> Page 3
> Active Usings: None
> 0 Loc Object Code Addr1 Addr2 Stmt Source Statement
> HLASM R4.0 2004/05/27 10.48
> 0000000 00000 01002 1 TEST CSECT
> 000000 2 DS CL4094''
> 000FFE 00000000 3 DC AL4(TEST)
> 001002 4 DS 0C
> 5 END
> ?????
>
> Shall we take this thread to ASSEMBLER-LIST?
>
> -- gil
>
Gil,
Was one of the parms in the assembler noalighn ?
Ed
Greg Dyck
> reason. I can't imagine "NOPRIME" working out correctly for a program
> object loaded in the common area and referenced by disabled programs.
> But perhaps I'm just overly cautious.
There are internal rules for when PRIME can be honored. My memory is that a
directed load will force all of the object to be loaded, no matter what has
been specified for PRIME.
Greg
Jeffrey D. Smith
> From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
> Behalf Of Ed Gould
> Sent: Thursday, May 27, 2004 11:43 AM
> To: IBM-...@BAMA.UA.EDU
> Subject: Re: before execution does it require whole program 2 b loaded
> in
>
>
> > Page 3
> > Active Usings: None
> > 0 Loc Object Code Addr1 Addr2 Stmt Source Statement
> > HLASM R4.0 2004/05/27 10.48
> > 0000000 00000 01002 1 TEST CSECT
> > 000000 2 DS CL4094''
> > 000FFE 00000000 3 DC AL4(TEST)
> > 001002 4 DS 0C
> > 5 END
> > ?????
> >
> > Shall we take this thread to ASSEMBLER-LIST?
> >
> > -- gil
> >
>
> Gil,
>
> Was one of the parms in the assembler noalighn ?
Irrelevant. The explicit length on the adcon operand
disables alignment for that operand.
--
Cheers
rsvp via e-mail (plain text) is preferred.
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS!
Are ISV upgrade fees too high? Check our custom product development!
Chase, John
> From: Ed Gould
>
> 1
> > Page 3
> > Active Usings: None
> > 0 Loc Object Code Addr1 Addr2 Stmt Source Statement
> > HLASM R4.0 2004/05/27 10.48
> > 0000000 00000 01002 1 TEST CSECT
> > 000000 2 DS CL4094''
> > 000FFE 00000000 3 DC AL4(TEST)
> > 001002 4 DS 0C
> > 5 END
> > ?????
> >
> > Shall we take this thread to ASSEMBLER-LIST?
> >
> > -- gil
> >
>
> Gil,
>
> Was one of the parms in the assembler noalighn ?
I believe it's the DC AL4( ) rather than DC A( ) that gives the non-word
alignment (allows byte-alignment, IIRC).
-jc-
Craddock, Chris
> 000000 2 DS CL4094''
> 000FFE 00000000 3 DC AL4(TEST)
> 001002 4 DS 0C
> 5 END
Explicit length trumps basic type. Remove the length modifier
and try it again...
Chris
Craddock, Chris
> was your practice not to run disabled unless you knew that
> any storage you were referencing was fixed;
True - always has been.
> NOPRIME adds nothing new.
Not true. Prior to the advent of program objects a LOAD macro
got the whole module into memory. Issue a LOAD for a program
object bound with NOPRIME (the default) and all you know is
the address of the primary entrypoint.
That address is -probably- in memory and depending on other
considerations (PACK/NOPACK, ALIGN...) it may all be in memory,
or some subset may be. The behavior is not clearly documented
and ETRs indicate it may not behave as documented anyway.
I am not saying this necessarily breaks anything, but its
entirely possible that code exists out there with implicit
assumptions based on the original behavior of LOAD that may
be "surprised" by the new behavior. I know we ran into some
goofy corner cases when we started using program objects on
a large scale.
> Even were the entire program loaded into storage it could be
> paged out in the time between load and reference.
True.
Ray Mullins
Remember our good friend OVLY? That certainly is an example of a
program not being wholly loaded for execution. :-)
I haven't checked recent COBOL standards - are there still provisions
for overlays in section names?
Thank <insert deity here> that I never had to deal with overlays...
--
M. Ray Mullins - Software Developer
CIMS Lab, Inc.
Roseville, CA, USA
Craddock, Chris
> present problems regardless of whether the module was loaded into
> private or common storage or whether it was bound with
> NOPRIME or PRIME.
> The obvious remedy is page fixing the parts of the module needed by
> disabled code. This should be required in all cases.
Yes and I assume contents supervision "does the right thing" in the
cases where we take the trouble to tell it what we want.
If I need to load executables into common these days I use LOAD with
GLOBAL=YES (or GLOBAL=(YES,F) if I need fixed storage.) This works,
so I assume the system does whatever it needs to in order to ensure all
of the pages are in fixed storage when it sees the "F" option.
I have verified that loading a (pageable) program object into common
storage with a plain old "LOAD GLOBAL=YES" works just fine. Just "how"
that is done is only a minor curiosity. I am not sure DIV is used when
the target is in common, but I really just don't know. If DIV isn't used,
the whole program object must be loaded.
Prior to the availability of the "GLOBAL" option I used directed loads
which would not have been an issue as I was providing the storage anyway
and had full control over its attributes. Its not spelt out anywhere but
I believe that in this case they fetch all of the pages regardless of
the properties of the designated storage.
Chris
gil...@ibm-main.lst
> Date: Thu, 27 May 2004 13:43:51 -0500
>
> Explicit length trumps basic type. Remove the length modifier
> and try it again...
>
Excuse me. What do you expect that to prove? Recapitulating
our earlier dialogue:
In a recent note <Chris_C...@BMC.COM> said:
> Date: Thu, 27 May 2004 10:30:27 -0500
>
> > Worse, if the ADCON is (mis-)aligned to cross a page boundary,
>
> Can't be. ADCONS are always word aligned and will never "cross"
> a page boundary.
>
Barring a Humpty-Dumptyesque semantic, I hope I can take
"always" to mean "for any form of ADCON", and "never" to
mean "not, regardless of options specified in PARM."
To refute your contention, I need show only a single instance
of an unaligned ADCON. I have done so, and Mr. Gould has
suggested another. Your argument of "always" and "never"
is not reinforced by showing one, or even several, instances
of aligned ADCONs.
I suppose the Binder could reject the NOPRIME option if the
load module contains unaligned ADCONs. I don't suspect this
is the case.
And I overlooked that each page has two boundaries, each of
which may contain an ADCON fragment. So the chain of
logical page faults may extend arbitrarily far in both
directions. (But at least it can't branch.)
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Eric Chevalier
jeffre...@ibm-main.lst (Jeffrey D. Smith) wrote:
>Irrelevant. The explicit length on the adcon operand
>disables alignment for that operand.
I think it's VERY relevant. The original issue was a relocatable ADCON
split across a page boundary. Chris Craddock claimed:
On 27 May 2004 08:31:31 -0700, Chris_C...@ibm-main.lst (Craddock,
Chris) wrote:
>Can't be. ADCONS are always word aligned and will never "cross"
>a page boundary.
Gil then posted a bit of sample code showing an ADCON that DID cross a
page boundary. This was followed by a bit of discussion to the effect that
word aligment of his ADCON was suppressed by an explicit length specifier.
I'll take Gil's example a small step further:
External Symbol Dictionary
Symbol Type Id Address Length LD ID Flags Alias-of
TEST SD 00000001 00000000 00001002 00
Active Usings: None
Loc Object Code Addr1 Addr2 Stmt Source Statement
000000 00000 01002 1 TEST CSECT ,
000000 2 DS CL4094
000FFE 00000000 3 DC AL4(TEST)
4 END ,
Relocation Dictionary
Pos.Id Rel.Id Flags Address
00000001 00000001 0C 00000FFE
Notice the RLD table? Maybe I'm missing something, but that sure looks to
me like a relocatable address that splits across a page boundary AND WOULD
NEED TO BE RELOCATED AT LOAD TIME. I think Gil's original example (and my
RLD table) tend to support the notion that a program object built with the
NOPRIME option could cause an interesting situation where a page brought
into memory causes a second page fault as a result of trying to relocate
an address.
Some of y'all seem to be fixated on the idea that the presence (or
absence) of an explcit length modifier is signifcant in some way. I don't
think that's the case; at runtime, a non-aligned, relocatable ADCON seems
to be perfectly acceptable to the system.
Eric
--
Eric Chevalier E-mail: et...@tulsagrammer.com
Web: www.tulsagrammer.com
Is that call really worth your child's life? HANG UP AND DRIVE!
Edward E. Jaffe
>Prior to the availability of the "GLOBAL" option I used directed loads
>which would not have been an issue as I was providing the storage anyway
>and had full control over its attributes. Its not spelt out anywhere but
>I believe that in this case they fetch all of the pages regardless of
>the properties of the designated storage.
>
That would make sense. Indeed, in
http://bama.ua.edu/cgi-bin/wa?A2=ind0405&L=ibm-main&P=R86433&I=1, Greg
Dyck recalls directed loads ignore the NOPRIME option (good to know). I
wouldn't be at all surprised to find similar behavior for GLOBAL loads
-- fixed or otherwise.
To their credit, IBM seems to have chosen the best possible handling
(IMHO) of NOPRIME. Their implementation, which ignores the option for
certain potentially problematic circumstances, allows the developer to
specify (or default to) NOPRIME without having to evaluate the
consequences on all current and possible future uses of the program object.
Re: the question of unaligned ADCONs: If it were me, I would force the
next page to be loaded when, at ADCON relocation time, I discovered an
ADCON that spanned a page boundary. Seems simple enough.
--
-----------------------------------------------------------------
| Edward E. Jaffe | |
| Mgr, Research & Development | edj...@phoenixsoftware.com |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
-----------------------------------------------------------------
----------------------------------------------------------------------
john gilmore
facultative/enabling but not directive: it permits but doies not require
that (minimally) only that portion of a program object that contains its
primary entry point be brought into virtual storage initially.
This issue is important to me, and I have begun a set of experiments in my
sandbox that will I hope identify the circumstances in which NOPRIME is
'honored' and those in which it is ignored.
When I have what seem to me to be robust and useful results, I will post
them in a table.
These results will have obvious limitations: They will reflect only the
current behavior of the execution loader at a point in time. It would be
helpful to have better guidance from IBM, but I am resigned to the fact that
what is in some sense gratuitous experiment is now often necessary in the
OCO world in which we perforce live.
John Gilmore
_________________________________________________________________
Best Restaurant Giveaway Ever! Vote for your favorites for a chance to win
$1 million! http://local.msn.com/special/giveaway.asp
john gilmore
black swan suffices to refute the generality 'There are no black swans'.
That conceded, the facility for specifying the explicit length of an A-type
ADCON in the interval .1 to 4 is provided for use by those who know, and who
presumably understand and intend the perhaps bizarre (but in some contexts
useful) consequences of its untoward use.
Moreover, as Paul well knows, Chris knows these things. There is thus more
empty rhetoric than substance in Paul's arguments: Ordinary A-type ADCONs do
not cross page boundaries, and the production of pathological
counter-examples does not change this.
John Gilmore
_________________________________________________________________
MSN Toolbar provides one-click access to Hotmail from any Web page – FREE
download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/
ibm-main
you can wake up to (typically) nearly complete threads.
Thanks to the "usual suspects" - plus the occasional ring-in - some
threads (like this) provide some light reading prior to any thoughts of
real work.
Most entertaining - including the curve ball from Paul that spawned the
sub-thread.
Shane ...
Jim Mulder
> facultative/enabling but not directive: it permits but doies not require
> that (minimally) only that portion of a program object that contains its
> primary entry point be brought into virtual storage initially.
> This issue is important to me, and I have begun a set of experiments in
my
> sandbox that will I hope identify the circumstances in which NOPRIME is
> 'honored' and those in which it is ignored.
> When I have what seem to me to be robust and useful results, I will post
> them in a table.
> These results will have obvious limitations: They will reflect only the
> current behavior of the execution loader at a point in time. It would
be
> helpful to have better guidance from IBM, but I am resigned to the fact
that
> what is in some sense gratuitous experiment is now often necessary in
the
> OCO world in which we perforce live.
Loader uses the following methods to fetch program
objects: Move, Directed, Page, Immediate,
Compressed, Overlay, Staged and HFS as follows:
1. Move mode is done by mapping text and relocation
information (XXXX) to high end storage. Text is then
moved and relocated to the storage area acquired for
the program.
2. Directed load is like move mode except that no record
is kept of the program.
YYYY and XTLST are acquired to simplify Loader
processing. The YYYY is freed before return from
Loader. Contents frees the extent list before
returning to its caller.
The user is responsible for
acquiring storage for the program. If the program
is in compressed format (see below), the processing
of the program will differ somewhat.
If the program consists of multiple loadable segments,
the segments will be placed contiguously within the
user-provided storage.
2a. Directed_Fetch is a variant of directed load that is
used by Dynamic LPA. It supports split-mode modules.
Control structures needed to support loading of
deferred segments is obtained in CSA with OWNER=SYSTEM.
3. Page mode is done by mapping the text to the storage
acquired for the program (on a 4K boundary). The XXXX
is retrieved and copied to DREF'ed storage. The
first section of the program is page loaded at program
load time. After that relocation is done at page
fault time by the page fault relocation exit.
4. Immediate load is done by mapping the text into the
area getmained for the program object. Then the routine
is immediately relocated and the pages loaded.
5. Immediate relocate, or relocate, described below, is
not supported in PM2, & all code supporting it has
been deleted.
-- Immediate relocate is done by first mapping the text
into the area getmained for the program object. The
pages that require relocation are relocated
immediately. The remaining pages of the program are
left mapped to be brought in when page faults occur.
6. Compressed load is done by mapping the text/XXXX page
to high end storage and then moving and relocating
the text to the storage area acquired for the program.
Note that directed load may be requested by the caller
for a program in compressed format.
7. For overlay, the text of the root segment is brought
in in much the same way as move mode. The remaining
segments are brought in upon request.
8. Staged load uses the same fetch algorithm as directed
load except that the relocation data is moved to the
doubleword boundary just beyond the last byte of text
data. The program is not relocated and the relocation
data is returned with the text data.
For a multi-segment module, the segment table and the
ZZZZ precede the XXXX.
9. HFS load is similar to compressed load, except that
copying the text/XXXX data to virtual storage is done
by calling HFS LSEEK and read instead of by using
DIV. Loader calls HFS CLOSE to free all HFS
resources after the text and RLD data has been read.
For PM-2 level program objects, pages of uninitialized
storage are not recorded on DASD, but are described by a
Gas Table (GSTB) within the Loader Data. For page and
immediate loading of modules that contain gas, the Loader's
Gas Exit uses a DREFd copy of the GSTB to allow
DIV to materialize gas pages
during page fault or Pgloads. For those load modes that
involve moving text from the buffers into which it is
DIV Mapped, i.e., for move, compressed, directed and
staged loads, the gas table is used in determining the
target address for the text.
The load method to be used depends on options specified
to the Binder when the program was created, on options
specified by the user to Contents Supervisor, by Contents
Supervisor and on the "tuning knobs" maintained by PML.
1. Directed load is used if requested by the caller.
2. Staged load is used if requested by the caller.
3. Compressed load is used if the program is marked as
compressed format by the Binder. Note that directed
and staged load can be called for on a compressed
format program.
4. Move mode load is used if the program is not loaded to
a 4K page boundary (if Binder option PACK was
specified, for example). Move mode is also forced if
the program is to be loaded to a private area subpool
in a V=R region or if it is to be loaded to a common
subpool or if it is to be loaded to a page fixed
subpool. The rationale is that (A) DIV doesn't
support MAP to a fixed area and that (B) for programs
in common which may be invoked by multiple address
spaces, DIV can only handle page faults in the
original address space. DIV always requires an even
4K area to be mapped.
5. Page mode is the normal default otherwise.
6. Immediate load is used for programs where:
a. There is less than "priming size" of text
b. Or the user requested "PRIME" and the program
is loaded on a 4K boundary.
c. Or the user requested "NOPRIME" but the program
requires too much fixed storage for XXXX and a
high percentage of the text pages require
relocation.
8. Overlay is always used for programs in overlay format.
9. HFS LOAD is used if the SMDE and the HFS file
descriptor are passed. *
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Jim Mulder
> next page to be loaded when, at ADCON relocation time, I discovered an
> ADCON that spanned a page boundary. Seems simple enough.
SINCE ONLY ONE PAGE OF TEXT IS RELOCATED AT A TIME,
THE POSSIBILITY EXISTS THAT AN ADCON MAY OVERLAP A
PAGE BOUNDARY. ONLY THE PART OF THE ADCON THAT FALLS
WITHIN THE CURRENT PAGE WILL BE UPDATED.
THE CONTENTS OF THE ADCON WILL BE KEPT IN THE xxxx
ENTRY. THIS IS NECESSARY SINCE WE MAY BE REQUIRED TO
RE-RELOCATE A PAGE. THAT IS WE MIGHT HAVE TO
RELOCATE A PAGE THAT HAS ALREADY BEEN RELOCATED AT A
DIFFERENT ADDRESS. IN ADDITION THE POSSIBILITY
EXISTS THAT AN ADCON MAY SPAN TWO PAGES OF TEXT BUT
WE WOULD BE REQUIRED TO RELOCATE ONE PAGE WITHOUT
HAVING ACCESS TO THE OTHER PAGE.
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
----------------------------------------------------------------------
Anne & Lynn Wheeler
> Can't be. ADCONS are always word aligned and will never "cross"
> a page boundary.
CMS convention has violated that since possibly 1965(?). the original
kernel call mechanism in cms was an svc 202 with a pointer in register
one that pointed to a parameter list. the first token in the
parameter list was the requested function. it turns out it is the same
interface used for typed commands and shell commands (one of the
things that made cms so easily extendable was the consistency of its
execution interface). in any case a cms kernel call was either
svc 202
dc al4(address)
instructions
or
svc 202
instructions
if there was an error, the return would check for a byte of zeros
following the svc and assume it was an address and branch to the
address location. if there wasn't a zero, it would assume there was no
error handling and go off to a default system provided one.
if there was no error, it would check for a zero following the svc,
and if it found one it would return to the svc interrupt address plus
four (i.e. skipping the presumed adcon). if the byte following the svc
wasn't zero, it would just return to the address of the svc interrupt.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
john gilmore
in an earlier post, more promptly than I should have thought possible. I
have not digested it fully, but it is already clear that he has answered
many, probably most of of the questions I had.
His response is clearly a very helpful one, and I for one am grateful for
his 'beyond the call of duty' effort. At worst, his categories provide an
enormously useful framework for getting answers toi any remaining, detailed
questions he may not have addressed.
John Gilmore
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
----------------------------------------------------------------------
Anne & Lynn Wheeler
> Gil then posted a bit of sample code showing an ADCON that DID cross a
> page boundary. This was followed by a bit of discussion to the effect that
> word aligment of his ADCON was suppressed by an explicit length specifier.
note that the original virtual machine system was circa 1965 with a
custom modified 360/40 with virtual memory translation hardware. cp/40
and cms was built for this machine. when ibm started shipping the
standard virtual memory 360 product, 360/67, cp and cms was ported to
the cp/67 (360/67 address translation had a lot of similarities to 370
address translation, however the custom 360/40 hardware translation
control was quite a bit different).
in any case, cms has been using the dc-al4() convention following a
two byte svc instruction for just short of 40 years ... and probably
half of them are half-word aligned ... and some percentage happen to
cross page boundaries.
Anne & Lynn Wheeler
> Moreover, as Paul well knows, Chris knows these things. There is thus more
> empty rhetoric than substance in Paul's arguments: Ordinary A-type ADCONs do
> not cross page boundaries, and the production of pathological
> counter-examples does not change this.
the cms standard scenario couldn't really be considered pathelogical
... the dc-al4() convention following a two-byte svc202 instruction
was totally embedded in nearly every kernel module and all application
code. at one time it was the ONLY way that programs could be invoked
in cms.
gil...@ibm-main.lst
> Date: Thu, 27 May 2004 21:19:47 +0000
>
> Paul Gilmartin's logic is in a sense impeccable:The production of a single
> black swan suffices to refute the generality 'There are no black swans'.
>
Thanks.
> That conceded, the facility for specifying the explicit length of an A-type
> ADCON in the interval .1 to 4 is provided for use by those who know, and who
> presumably understand and intend the perhaps bizarre (but in some contexts
> useful) consequences of its untoward use.
>
At one time, AL3() was used pervasively, perhaps by both coloro che sanno
and mandolinisti. I suspect its vestiges are yet prevalent.
> Moreover, as Paul well knows, Chris knows these things. There is thus more
> empty rhetoric than substance in Paul's arguments: Ordinary A-type ADCONs do
> not cross page boundaries, and the production of pathological
> counter-examples does not change this.
>
I don't well know what Chris knows. But I was startled by his use
of "always" and "never" where you and I would more properly use
"ordinarily" and "pathologically".
But the nub of the discussion was my observation that for a NOPRIME
program object the page fault handler (ASM? DIV? Whatever?) must
be prepared to deal with ADCONs that cross page boundaries. I grant
this would be false if Chris's generality were true. But a successful
program must be able to deal with the pathological occurrence as well
as the ordinary.
I plead "not guilty" to the charge of "empty rhetoric" and stand
by my initial observation.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Craddock, Chris
> of "always" and "never" where you and I would more properly use
> "ordinarily" and "pathologically".
On that count you were right and I was wrong. "ordinarily" and
"pathologically" would have been better choices of words. I really
did not consider the pathological case. Mea Culpa.
> But the nub of the discussion was my observation that for a NOPRIME
> program object the page fault handler (ASM? DIV? Whatever?) must
> be prepared to deal with ADCONs that cross page boundaries.
Jim's note seems to have cleared that up. ADCONS that cross page
boundaries are kept "elsewhere" and only the portion that falls
into the specific page being relocated is modified. So it -is-
prepared to deal with page crossings, albeit in an unobvious way.
Chris
Anne & Lynn Wheeler
> At one time, AL3() was used pervasively, perhaps by both coloro che sanno
> and mandolinisti. I suspect its vestiges are yet prevalent.
... note as an aside ... a lot of the os system services macros forced
alignment of mixed data & instructions with appropriately generated
cnops (program origins were assumed to be at a minium double word
aligned ... so system services macros could calculate alignment at
double word level by the displacement from the program origin and
taking on faith the program would be at a minimum double word
aligned).
cms system call macros skipped the cnops and just allowed fullword
constants (even relocatable adcons) to be half-word aligned following
the svc instruction.
Greg Dyck
> sandbox that will I hope identify the circumstances in which NOPRIME is
> 'honored' and those in which it is ignored.
It should *not* be important, because it is invisible to you (except,
*possibly*, some non-home cross-memory cases which cause an unresolvable
page fault). That was part of the design, and this is a fact that seems to
have been lost in this discussion.
A page that is not immediately loaded at fetch time looks like a page that
is paged out. If you reference the page it is "paged in" either from the
program library or auxillary storage. If you fix the page it is "paged in"
and fixed. If you load into fixed storage the page must be immediately
loaded from the program library.
Don't worry about this. Be happy.
Greg
gil...@ibm-main.lst
> Date: Sat, 5 Jun 2004 10:05:37 -0700
>
> 1. A method for expanding the functionality of an APPLICATION BUTTON on
> a LIMITED RESOURCE COMPUTING DEVICE, comprising:
>
> This has nothing to do with mice. This has nothing to do with PCs. A
> "limited resource computing device" would have to be something like an
> MP3 player or a PDA (NOT a mouse or a PC). This wording was no doubt
>
> This is in fact a new and cool idea. On a PDA (only!) it says that if
>
The "only!" part is what leads me (and if I understand correctly,
Shmuel) to disagree strongly with you. It appears that you (and
Microsoft) consider it a patentable innovation to restrict the
scope of application of an existing technique.
Suppose Honda had applied for "A method for controlling the direction
of progress of a hybrid gas-electric powered motor vehicle ..."
and proceeded to seek a patent on the use of the steering wheel
in hybrid (only! not gasoline or steam or diesel) powered cars.
The fact that a steering wheel was never used previously in a
hybrid powered car does not justify any claim of innovation.
This sort of thing should not be allowed to happen, even with
negotiation between the soi-disant inventor and the PTO.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Charles Mills
I don't want to be guilty of starting or participating in another one.
So this will be my last post on this topic. I will say only three
things:
1. Patent is a specialized field. If it were possible to become an
expert in patents by studying OS/390 systems programming, then a lot of
bright people - many of them engineers before they were patent attorneys
- have wasted five years of their lives. You'd laugh if some patent
expert decided that his patent studies qualified him to configure SMP/E.
2. A steering wheel for a hybrid device would in fact fail the
obviousness test, and that's presumably why Honda has NOT patented it.
That is, an average practitioner aware of the entire art of vehicle
steering devices would in an instant realize that a steering wheel would
make sense on a hybrid vehicle. That is the patent law test of
obviousness. Not so (IMHO) for holding down a Word button on a PDA as a
way of parametizing an application. No one at Palm apparently thought of
it. Therefore it must NOT be all that obvious. The law has never
required "innovation" and the term is meaningless in the context of
patent law. To be patentable, a device must be useful, novel (in patent
law that means newly-invented, not something you invented years ago and
just now realized you might patent), and non-obvious. That's the way it
has always been. It's not some new problem with patents.
3. IMHO the reform that is needed is very simple: reducing the TERM of
technology patents. Giving Eli Whitney a twenty-year legal monopoly may
have made sense way back when. But to give MS a monopoly on a technical
innovation for a period that may exceed the entire life of the PDA - who
knows what we will be using in 2024? - seems excessive to me. It's a
very simple reform - much less contentious (IMHO) than debating a
refinement of the term of art "obvious" or whether or not business
methods should be patentable. Much less likely to introduce some new
undesirable wrinkle. But please don't blame the PTO that your elected
representatives have not seen fit to legislate this reform.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Behalf Of Paul Gilmartin
Sent: Sunday, June 06, 2004 8:19 AM
To: IBM-...@BAMA.UA.EDU
Subject: Re: Innovation lives! (aka Microsoft did NOT patent the
Suppose Honda had applied for "A method for controlling the direction of
progress of a hybrid gas-electric powered motor vehicle ..." and
proceeded to seek a patent on the use of the steering wheel in hybrid
(only! not gasoline or steam or diesel) powered cars.
The fact that a steering wheel was never used previously in a hybrid
powered car does not justify any claim of innovation. This sort of thing
should not be allowed to happen, even with negotiation between the
soi-disant inventor and the PTO.
----------------------------------------------------------------------
Phil Payne
http://www.washingtonpost.com/wp-dyn/articles/A15187-2004Jun4.html
--
Phil Payne
http://www.isham-research.com
+44 7785 302 803
Efinn...@ibm-main.lst
char...@MCN.ORG writes:
This forum seems prone to hosting barely on topic spitting contests and
I don't want to be guilty of starting or participating in another one.
So this will be my last post on this topic. I will say only three
things:
>>
bitnet. Subscribers include developers from a number of MF venders, mostly
dedicated to making
better and easier to use products and methodologies. We're pretty open to
innovation introduced by bright ideas, not so open to change for the sake of
fiat(or Audi either).
Darren's got filters and exits in place to keep us on track and despammed.
They work, but human nature's kinda funny. If you spit at someone they'll
generally spit back. This usually goes on 'til it deteriorates into hardware recalls
and MFCM's. The posters then get set to NOPOST or worse.
gil...@ibm-main.lst
> Date: Tue, 8 Jun 2004 15:08:14 -0700
>
> I'm hoping I've missed something in the documentation. Does anyone know
> of a way to override the DD names INPUT and OUTPUT used by the OS/390
> FTP client when invoking it with LINK, XCTL, or ATTACH? One would need
> to do this, for example, if one were to ATTACH more than one copy of the
> FTP client simultaneously in the same jobstep.
>
Use fork() or spawn() with _BPX_SHAREAS=NO to invoke FTP in a
separate address space. Then there will be no DDNAME conflicts.
> What I'm looking for is a facility similar to that supported by many
> OS/390 compilers and utilities in which one can change the conventional
> DD names by passing a list of overrides as parameter two -- or any other
> reasonably equivalent facility.
>
As I've said before, this is another example of IBM's doing the
Right Thing in the Wrong Place. DDNAME mapping should have been
done by ATTACH, not by the program being ATTACHed. Then the code,
written once, would have supported every program with no effort
on the part of the application/utility developer.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Charles Mills
of a way to override the DD names INPUT and OUTPUT used by the OS/390
FTP client when invoking it with LINK, XCTL, or ATTACH? One would need
to do this, for example, if one were to ATTACH more than one copy of the
FTP client simultaneously in the same jobstep.
What I'm looking for is a facility similar to that supported by many
OS/390 compilers and utilities in which one can change the conventional
DD names by passing a list of overrides as parameter two -- or any other
reasonably equivalent facility.
Is there a mainframe FTP discussion list where this query would be more
appropriate?
Thanks,
Charles Mills
Ask the experts at SoftwareCEO.com/forums
Nix, Robert P.
I use a Sharp Zaurus as my PDA. At least two of the buttons on Zaurus are dual purpose, based on how long you press them down: The Cancel key is cancel if you press and release it, but is power off if you hold it down. The Menu key opens the menu if you press it, but turns on and off the back-light if you hold it down.
On the Palm devices (at least the ones I've seen and used), pressing the power button and releasing it turns the device on and off, but pressing it and holding it down causes a window to appear that allows you to change the brightness of the screen.
Are these not examples of multi-purpose buttons based on time delay on a limited resource device?
----
Robert P. Nix internet: nix.r...@mayo.edu
Mayo Clinic phone: 507-284-0844
RO-CE-8-857 page: 507-270-1182
200 First St. SW
Rochester, MN 55905
---- "Codito, Ergo Sum"
"In theory, theory and practice are the same,
but in practice, theory and practice are different."
> -----Original Message-----
> From: IBM Mainframe Discussion List [SMTP:IBM-...@ibm-main.lst
> Sent: Sunday, June 06, 2004 10:55 AM
> To: IBM-...@BAMA.UA.EDU
> Subject: Re: Innovation lives! (aka Microsoft did NOT patent the
>
>
> way of parametizing an application. No one at Palm apparently thought of
> it. Therefore it must NOT be all that obvious. The law has never
>
----------------------------------------------------------------------
gil...@ibm-main.lst
> Date: Fri, 2 Jul 2004 13:42:57 -0500
>
> on 7/2/04 1:38 PM, john gilmore at john_w_...@MSN.COM wrote:
>
> > generation of a set of one or (often) more HLASM DSECTs from a PL/X
> > structure declaration is a task that can be largely if not perhaps quite
> > completely mechanized/automated; but nothing of this sort has been done,
> > chiefly, I suspect, because IBM has adopted an implicit policy of benign
> > neglect.
>
> Sounds like an SHARE requirement to me:)
>
Since (it is generally believed) the PL/X compiler generates assembler
language, one might naively assume that it is necessary only to capture
the PL/X output of compiling a macro in order to obtain an assembler
version. Of course, this isn't so. It's likely that PL/X doesn't
emit a complete assembler version of the macro, but builds internal
structures and employs those in compiling the open code of a program.
But it could be made so, with suitable changes to the PL/X compiler.
For example, the PL/X preprocessor conditionals would need to be
not elaborated by the compiler, but translated to suitable AIF constructs.
Only so could the needed testing be assured, in that it would happen
collaterally to compilation of IBM's own components.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Craddock, Chris
> language, one might naively assume that it is necessary only
> to capture
> the PL/X output of compiling a macro in order to obtain an assembler
> version. Of course, this isn't so.
Its my understanding that the PL/X compiler really is a compiler.
What you get out of it is object code and a listing. Not really
a good basis for doing mapping macros for assembler programmers.
But I have also heard that it generates assembler. So one of the
knowlegeable Beemers will have to set us straight on that.
IBM uses a tool to convert the PL/X declarations to ASM. We've
discussed it here before and Peter Relson weighed in on it. See
<http://bama.ua.edu/cgi-bin/wa?A2=ind0209&L=ibm-main&P=R82655&I=1>
Basically there are gaps in their process and the result is that
the assembler portions of the macro can be significantly different
than the PL/X portions unless the developer is meticulous about
running the PL/X->ASM perverter after all the changes in the PL/X
code have been finalized.
Chris
Edward E. Jaffe
>Its my understanding that the PL/X compiler really is a compiler.
>What you get out of it is object code and a listing. Not really
>a good basis for doing mapping macros for assembler programmers.
>
>But I have also heard that it generates assembler. So one of the
>knowlegeable Beemers will have to set us straight on that.
>
You don't need to be a "knowlegeable Beemer" to know this. Just inspect
a listing in VPL (if you can find a module that isn't OCO). PL/X
produces input to HLASM.
>IBM uses a tool to convert the PL/X declarations to ASM. We've
>discussed it here before and Peter Relson weighed in on it. See
><http://bama.ua.edu/cgi-bin/wa?A2=ind0209&L=ibm-main&P=R82655&I=1>
>
>Basically there are gaps in their process and the result is that
>the assembler portions of the macro can be significantly different
>than the PL/X portions unless the developer is meticulous about
>running the PL/X->ASM perverter after all the changes in the PL/X
>code have been finalized.
>
The tool was originally intended to be used once, to create a biligual
mapping from a PL/X mapping. Not over and over to make incremental
changes to an existing macro.
--
-----------------------------------------------------------------
| Edward E. Jaffe | |
| Mgr, Research & Development | edj...@phoenixsoftware.com |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
-----------------------------------------------------------------
----------------------------------------------------------------------
gil...@ibm-main.lst
> Date: Tue, 6 Jul 2004 09:15:31 -0700
>
> Craddock, Chris wrote:
>
> >IBM uses a tool to convert the PL/X declarations to ASM. We've
>
> The tool was originally intended to be used once, to create a biligual
> mapping from a PL/X mapping. Not over and over to make incremental
> changes to an existing macro.
>
So: write a simple executive (Rexx should suffice) which takes as
input a bilingual mapping and discards the assembler part leaving
pure PL/X, then feeds that into "The tool". Voila! you have a
second-generation tool that can be used over and over to convert
changes made incrementally to the PL/X part.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Jim Mulder
> >
> > The tool was originally intended to be used once, to create a biligual
> > mapping from a PL/X mapping. Not over and over to make incremental
> > changes to an existing macro.
> >
> So: write a simple executive (Rexx should suffice) which takes as
> input a bilingual mapping and discards the assembler part leaving
> pure PL/X, then feeds that into "The tool". Voila! you have a
> second-generation tool that can be used over and over to convert
> changes made incrementally to the PL/X part.
The tool aready does that, and I certainly use it to make
incremental changes. I trust the tool more than I trust my
ability to correctly write assembler DSECTs. The complaints about
the tool were generally about the readability of the assembler
code it generates, not its accuracy. The accuray problems
mentioned earlier in this thread were probably with macros which
were bilingualized manually. Some macros are done by the tool, but
there are still a lot of old ones which are done manually.
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
----------------------------------------------------------------------
gil...@ibm-main.lst
> Date: Tue, 6 Jul 2004 14:42:46 -0400
>
> > second-generation tool that can be used over and over to convert
> > changes made incrementally to the PL/X part.
>
> The tool aready does that, and I certainly use it to make
> incremental changes. I trust the tool more than I trust my
> ability to correctly write assembler DSECTs. The complaints about
> the tool were generally about the readability of the assembler
> code it generates, not its accuracy. The accuray problems
> mentioned earlier in this thread were probably with macros which
> were bilingualized manually. Some macros are done by the tool, but
> there are still a lot of old ones which are done manually.
>
Why not, then, run the old macros through "the tool" and be
finished with manual maintenance? Symbol name inconsistencies?
Other specification incompatibilities?
Does "the tool" work for executable code macros as well as for
CB mapping macros?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Edward E. Jaffe
>The accuray problems
>mentioned earlier in this thread were probably with macros which
>were bilingualized manually. Some macros are done by the tool, but
>there are still a lot of old ones which are done manually.
>
I did get APAR OW53691 opened because of the erroneous (and totally
untested) changes made to IHALPDE -- a macro that was manually
bilingualized. But such macros have been the exception. The majority of
the problems I encountered had to do with programmers attempting to
manually change macros that were automatically bilingualized. In
particular, I've lost count of exactly how many times I complained about
BPXZODMV being updated erroneously.
Notwithstanding what's been stated above, I think you missed the point
completely, Jim. The problem being discussed in this thread has nothing
whatsoever to do with this or that tool. How the macros are updated is
irrelevant. The complaint is that IBM routinely DOES NOT TEST ITS
CHANGES to the assembler portion of the macros. IBM should test its
changes no matter which technique is used to update the macros! It's
common sense, common programming practice, and their responsibility to
do so.
--
-----------------------------------------------------------------
| Edward E. Jaffe | |
| Mgr, Research & Development | edj...@phoenixsoftware.com |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
-----------------------------------------------------------------
----------------------------------------------------------------------
Rick Fochtman
The accuray problems mentioned earlier in this thread were
probably with macros which were bilingualized manually. Some
macros are done by the tool, but there are still a lot of old
ones which are done manually.
Accuracy in the manual process is mainly attention to detail. I've
managed to convert a number of PL/X and ASM mappings to PL/1
declarations. It's tedious but possible.
gil...@ibm-main.lst
> Date: Thu, 5 Aug 2004 12:49:23 -0500
>
> You must create the CD with the "Rock Ridge" extentions for long file
> names on UNIX. Use "Joliet" extentions for Windows. I use both
> extentions (they are not mutually exclusive).
>
Thanks. Since I've upgraded to OS X 10.3 in the several months
since I tried the experiment, I burned a new CD. OS X help
asserts that this creates 3 directories:
o HFS
o ISO 9660 with Rock Ridge extensions
o Joliet with Rock Ridge extensions.
(From what I've been able to read, the third seems inconsistent;
do they perhaps mean, "ISO 9660 with Joliet extensions"?)
In any case, I see my filenames intact on a Windows system;
on Solaris they appear dossified. So it's finger pointing
time. How can I distinguish whether:
o OS X failed to generate the ISO 9660 Rock Ridge extensions
correctly?
o Solaris failed to recognize them?
"df" tells me:
auto_cdrom /proj/cdrom autofs indirect,ro,ignore,dev=4d00007 1091472903
/vol/dev/dsk/c0t2d0/gimzip2004_08_09 /cdrom/gimzip2004_08_09
hsfs maplcase,noglobal,nosuid,ro,rr,traildot,dev=16c0003
1092084900
I believe "hsfs" means "High Sierra File System". How is this
related to "Rock Ridge"? Does "rr" mean "Rock Ridge"?
Am I correct in not expecting to see "maplcase" if Rock Ridge
extensions are being honored?
Has anyone else any other suggestions?
Thanks again,
gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
gil...@ibm-main.lst
> Date: Wed, 11 Aug 2004 09:11:00 +1000
>
> There is no chance in hell of me allowing Vendor generated JCL to run
> without me eyeballing it first.
>
Prudent.
Does ShopzSeries generate JCL? Do readers of this list
eyeball it first?
I'm pondering periodically generating some JCL (similar function
to ShopzSeries) for our customers? How may I minimize the
eyestrain?
I'm considering inviting customers to save the first generated
job, after thorough eyeballing, as a reference, and to do an
ISRSUPC (or diff) and eyeball the DELTA for each subsequent
generation. I'd like to put as many as possible of the variables
in JCL SET statements clustered at the front. Some variables
necessarily appear in the scope of a SYSIN DD. I could either
rely on sporadic eyeballing, or use a PARM-to-file utility
(probably inline Rexx) to generate the SYSIN. I suspect that
while the former scatters the variables worse, its simplicity
makes it preferable.
Any suggestions?
Thanks,
Shane
> Does ShopzSeries generate JCL? Do readers of this list
> eyeball it first?
>
Being unable to use RECEIVEFROMNETWORK, I download and manually install.
Per se, I manage the jobs involved; changing order numbers principally.
JCL to accomplish this is offerred on the site.
> I'm pondering periodically generating some JCL (similar function
> to ShopzSeries) for our customers? How may I minimize the
> eyestrain?
>
Only ever ordered maint from Shopz - new product orders aren't available
in this neck of the woods. Or weren't when I last needed them.
Consequently changes are minimal - new file/DDDEF requirements are
generally the subject of HOLDDATA, and are handled separately to this.
Could be packaged, but are generally PTF specific rather than
necessarily "every site".
> I'm considering inviting customers to save the first generated
> job, after thorough eyeballing, as a reference, and to do an
> ISRSUPC (or diff) and eyeball the DELTA for each subsequent
> generation. I'd like to put as many as possible of the variables
> in JCL SET statements clustered at the front. Some variables
> necessarily appear in the scope of a SYSIN DD. I could either
> rely on sporadic eyeballing, or use a PARM-to-file utility
> (probably inline Rexx) to generate the SYSIN. I suspect that
> while the former scatters the variables worse, its simplicity
> makes it preferable.
>
I'd be happy with simplicity.
Compare/diff is part of the eyeball process. You will help your
customers by adding new at the end rather than trying to "shoe-horn" it
into the "current".
Compare (especially) doesn't necessarily handle insertions as well as
one might perhaps like.
Shane ...
gil...@ibm-main.lst
> Date: Wed, 11 Aug 2004 10:56:31 +1000
>
> Being unable to use RECEIVEFROMNETWORK, I download and manually install.
> Per se, I manage the jobs involved; changing order numbers principally.
> JCL to accomplish this is offerred on the site.
>
And you eyeball that JCL? Each time?
> Consequently changes are minimal - new file/DDDEF requirements are
> generally the subject of HOLDDATA, and are handled separately to this.
>
I'm thinking of a checksum in SYSIN, which is different for each package.
> Compare (especially) doesn't necessarily handle insertions as well as
> one might perhaps like.
>
> > ISRSUPC (or diff) and eyeball the DELTA for each subsequent
> >
> I'd be happy with simplicity.
>
Thanks. I had expected that.
> Compare/diff is part of the eyeball process. You will help your
> customers by adding new at the end rather than trying to "shoe-horn" it
> into the "current".
>
> Thanks. I don't know if that's feasible.
> Compare (especially) doesn't necessarily handle insertions as well as
> one might perhaps like.
>
I knew a wretched compare utility that had that defect. I won't name it
here. I have never encountered such a problem with either ISRSUPC or
diff.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 05:53 PM, Paul Gilmartin <gil...@UNIX.STORTEK.COM> said:
>I'm pondering periodically generating some JCL (similar function to
>ShopzSeries) for our customers? How may I minimize the eyestrain?
Put some skull sweat into accommodating customer naming conventions.
In particular, provide for meaningful job names as a default but allow
the user to specify a prefix to which you will append a suffix.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
gil...@ibm-main.lst
> Date: Wed, 25 Aug 2004 06:56:59 -0500
>
> I'm sorry but as an "old fart" in this game, I've always though of 1K
> as being 2^10 and moved forward from there. In radio, when I was a HAM
> many years ago, 1KHZ was 1,000 Hertz but 1KB was 2^10 bytes. Context
> made the difference. I feel sorry for the PFCSK's that aren't bright
> enough to see that context can make all the difference in the world.
>
I feel sorry for the traditionalists who would apparently yearn for
the pre-SI chaos which has left us with the need for two different
sets of weights to weigh on a balance an ounce of gold and and an
ounce of copper. (And which set does one use for a Cu-Au alloy?
Interpolate according to the fractional composition?) And liquid
vs. dry vs. Imperial volume units? Context? Spare me!
(But what about the engineers, who can't understand that
a kilogram is a unit of mass and a newton a unit of force,
and not vice-versa? And who believe accordingly that the
intuitive unit of specific impulse is the second?)
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
gil...@ibm-main.lst
> Date: Tue, 24 Aug 2004 16:36:14 -0700
>
> Taking this one step further, why did the IEC and NIST have to re-invent
> the wheel? Why not keep kilo-, mega-, and giga- for the powers of two
> and adopt the usage already common in the financial community of M for
> 10**3 and MM for 10**6?
>
I feel old. You are trying to mislead readers of this list to believe
the initial use of kilo-, mega-, and giga- was as powers of two.
Not as I remember it. In my youth, kilo- and mega- unequivocally
indicated powers of ten. (giga- hadn't been invented; I remember
the fanfare when giga-, tera-, nano-, and pico- were introduced
(or was that peta-, exa-, atto- and femto-? CRS.) And that I
was treated as a revisionist for once calling a capacitor five
nanofarads when custom dictated 5,000 micromicrofarads (pico- was
new, not commonly used) or .005 microfarads.)
But no powers of two. In fact computer memory addresses then
were decimal numbers to the hardware (preponderantly, not universally).
A 4K 1401 (if you could afford one) was 4,000 characters, not 4096.
But John G. may rightly feel older than I if his claim to be the
popularizer of "M" to indicate 1,000 in the financial community
is credited.
Charles Mills
industry. A kilometer is never going to be 1024 meters no matter what
usage the computer industry might adopt.
I still think gibibytes sounds too silly to ever catch on widely.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Behalf Of Paul Gilmartin
Sent: Wednesday, August 25, 2004 6:44 AM
To: IBM-...@BAMA.UA.EDU
Subject: Re: prefixes: powers of 2 and powers of 10 (was 64 Bit virtual
In a recent note, Charles Mills said:
> Date: Tue, 24 Aug 2004 16:36:14 -0700
>
> Taking this one step further, why did the IEC and NIST have to
> re-invent the wheel? Why not keep kilo-, mega-, and giga- for the
> powers of two and adopt the usage already common in the financial
> community of M for 10**3 and MM for 10**6?
>
I feel old. You are trying to mislead readers of this list to believe
the initial use of kilo-, mega-, and giga- was as powers of two. Not as
I remember it. In my youth, kilo- and mega- unequivocally
----------------------------------------------------------------------
Edward E. Jaffe
>I still think gibibytes sounds too silly to ever catch on widely.
>
>
And therein lies the crux of the problem. If it doesn't catch on widely,
it's going to create even more confusion than exists already.
I spent years referring to January 1, 2001 as the first day of the new
Millennium. Even had a party to celebrate (as many of my SHARE
colleagues may remember). The outcome? Most everyone thought I was
nuts! The populous believed the Y2K crossover was the start of the new
Millennium and the media did nothing to educate them otherwise -- in
fact just the opposite. [Sigh!]
I'll most likely be referring to 1024*1024*1024 somethings
"gigasomethings" until they pry that prefix from my cold dead teeth!
Besides ... the term "gibisomethings" just doesn't fit well with my LA
musician's persona! (Too nerdy.)
--
-----------------------------------------------------------------.
| Edward E. Jaffe | |
| Mgr, Research & Development | edj...@phoenixsoftware.com |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
'-----------------------------------------------------------------'
Ted MacNEIL
The populous believed the Y2K crossover was the start of the new Millennium
Mathematically & logically counting starts at zero.
Remember the discussion about 2^64 vs 2^64-1?
When you are born, you are in your first year, but you are zero years old.
Following, 2000 is the start of the first year of the new millenium.
-T
Campbell Jay
But there was never a year zero...... ugggh
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Behalf Of Ted MacNEIL
Sent: Tuesday, August 24, 2004 8:00 PM
To: IBM-...@BAMA.UA.EDU
Subject: Re: prefixes: powers of 2 and powers of 10 (was 64 Bit virtual
Ted MacNEIL
But there was never a year zero
..
Actually, there was.
The year before year one.
Plus, Jesus was actually born in 3BC.
Goforth, Mark
But there was never a year zero
..
Actually, there was.
The year before year one.
Plus, Jesus was actually born in 3BC.
..
Actually, no there wasn't. The Gregorian calendar goes from 1 BC to 1AD.
There is no zero year.
This email and any files attached with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error delete this message and
notify the sender at 402-341-0500. If you are not the named recipient you
should not disseminate, distribute or copy this email or any attachment.
Ted MacNEIL
Actually, no there wasn't. The Gregorian calendar goes from 1 BC to 1AD.
There is no zero year.
Semantics?
Mathematics?
Julian Calendar?
Opinions vary (obviously).
Nobody was ever sure which year was which due to lack of proper records.
I tend towards the logical/mathematical approach.
-T
Chase, John
> From: Ted MacNEIL
>
> ...
> The populous believed the Y2K crossover was the start of the
> new Millennium
>
> Mathematically & logically counting starts at zero.
> Remember the discussion about 2^64 vs 2^64-1?
>
> When you are born, you are in your first year, but you are zero years old.
>
> Following, 2000 is the start of the first year of the new millenium.
But since there was no "year zero", one of the preceding millennia would
contain only 999 years.
-jc-
Howard Brazee
> Mathematically & logically counting starts at zero.
"counting numbers" or "natural numbers" are the set of positive integers (not
including zero).
"starting" is a subjective term anyway. You start from where you start from.
If it happens to be mile marker 12, that's where you start. The people who set
up the Christian calendar didn't create a year zero. They also didn't create a
zeroeth century, but popular culture had no trouble believing that 1950 was part
of the 20th century.
If people want to change the year 2000 to be the start of the century - why not
make it the start of the 20th century to be consistent?
Or say the year 2001 is the start of the 21st century.
Having it both ways is illogical.
Howard Brazee
> But there was never a year zero
> ..
>
> Actually, there was.
> The year before year one.
Show me.
Was year zero part of century zero?
Greg Shirey
arguments about when the Millennium began?? Please stop. Please!
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Behalf Of Ted MacNEIL
Sent: Tuesday, August 24, 2004 7:00 PM
To: IBM-...@BAMA.UA.EDU
Subject: Re: prefixes: powers of 2 and powers of 10 (was 64 Bit virtual
..
But there was never a year zero
..
Actually, there was.
The year before year one.
Plus, Jesus was actually born in 3BC.
-T
Ted MacNEIL
Was year zero part of century zero?
What is your degree in? (8-{>}
Ted MacNEIL
Having it both ways is illogical
I never asked for it both ways.
I base my opinion on what I was taught in school, what I think about the zeroth year for a newborn, and what Dr. Asimov wrote about time-keeping in a 1950's article in ANOLOG.
This is opinion, not fact.
But, logically was already explained.
Stephen Y. Odo
I've heard that in some cultures you are considered "1" when you are
born. When we were stationed in Japan back in the '60s I remember an
old Japanese lady telling me that was how it was done there ... but I
never confirmed that (sorry, I was in elementary school) ... anybody know?
I know, I know ... this has absolutely nothing to do with this
discussion ... sorry ...
-Stephen
Ted MacNEIL
Logical would indicate that you have the same approach for naming centuries as you have for naming years. Was there a century zero?
..
0-999 was the first century.
0 the start of the first year.
-T
Jon Brock
old already.
Jon
<snip>
Nobody was ever sure which year was which due to lack of proper records.
I tend towards the logical/mathematical approach.
</snip>
Ted MacNEIL
Was there a century zero?
..
Just said everything started at zero.
-T
Ted MacNEIL
I'm still not sure which year is which. I mean, I can't possibly be this old already.
I agree, wholeheartedly.
I probably should not have responded to the part of this thread, regarding the start of new millenia, or whatever.
When does the year 2004 start?
Gerhard Postpischil
From: "Ted MacNEIL" <tedma...@ibm-main.lst>
> What is your degree in? (8-{>}
Celsius <G>
hyuugabaru
In Japan, before 1950, when a person was born, he is considered as one
year old. And every person adds one on his age at the New Year's Day.
On 1950, the new law defined and then, zero years old is used, and
adds one on his age at his birthday.
But even today, older counting way is used especially age at death in
Buddhism.
gil...@ibm-main.lst
> Date: Mon, 30 Aug 2004 09:08:39 -0400
>
> > Was I just dreaming, or does SMP/E now handle VB-format CLIST
> > libraries with the same "ease and aplomb" as FB CLIST libraries? I
> > have a dim memory of reading somewhere that changes to SMP/E allowed
> > FB CLIST maintenance to be applied to VB-format target libraries. Or
> > may be I was dreaming?
>
> You were not dreaming, although this support has been available for
> quite some time. Since OS/390 V2R7, SMP/E can install data elements
> (++CLIST for example) into target libs and dlibs based on the output
> data set attributes. That is, SMP/E will reformat the element as
> necessary, from FB to VB or VB to FB, and if the LRECLs are different.
>
Does this remove some (not all) of the requirement for GIMDTS?
Suppose the LRECLs are different? What are the rules for
truncation/padding?
There's an uncomfortable and risky amount of DWIM here, particularly
if the FUNCTION is delivered in RELFILE format. Suppose I package
a product with some data set in RECFM=VBA; LRECL=137 format, but the
customer, out of habit or skepticism, allocates as FB; 80. I'd prefer
to have the APPLY fail (or even the RECEIVE if the customer preallocates
the TLIBs) with "inconsistent DCB attributes" rather than some
inscrutable failure during execution.
As a vendor, I'd feel more comfortable if target libraries were
required to match the format of the distributed RELFILES, and
inline elements other than FB; 80 were required to be in GIMDTS
format, or at least have the attributes declared in the ++ ELEMENT
statement.
What are IEBCOPY's rules? What effort does SMP/E make to
relax them?
And for element updates (particularly in USERMODs), what support is
there for an update utility more welcoming of diversity of attributes
than IEBUPDTE, such as /bin/patch?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Kurt Quackenbush
>>necessary, from FB to VB or VB to FB, and if the LRECLs are different.
>
> Does this remove some (not all) of the requirement for GIMDTS?
Yes, it removes some requirements for GIMDTS. This reformatting is only
performed for data element, therefore, GIMDTS is still required for
other element types (HFS and PROGRAM).
> Suppose the LRECLs are different? What are the rules for
> truncation/padding?
In the SMP/E Commands book, the APPLY chapter, "Data Element and Program
Element Replacements" topic, there is a large table that describes the
combinations of supported RECFMs and LRECLs which I will not try to
reproduce here. There is also a discussion of truncation/padding, but
in a nutshell, blanks may be truncated and records may be padded with
blanks, and sequence numbers (if present) will be preserved.
> There's an uncomfortable and risky amount of DWIM here, particularly
> if the FUNCTION is delivered in RELFILE format. Suppose I package
> a product with some data set in RECFM=VBA; LRECL=137 format, but the
> customer, out of habit or skepticism, allocates as FB; 80. I'd prefer
> to have the APPLY fail (or even the RECEIVE if the customer preallocates
> the TLIBs) with "inconsistent DCB attributes" rather than some
> inscrutable failure during execution.
>
> As a vendor, I'd feel more comfortable if target libraries were
> required to match the format of the distributed RELFILES, and
> inline elements other than FB; 80 were required to be in GIMDTS
> format, or at least have the attributes declared in the ++ ELEMENT
> statement.
>
> What are IEBCOPY's rules? What effort does SMP/E make to
> relax them?
IEBCOPY's rules are rather strict, hence the SMP/E reformatting support.
The specific rules are described in the above mentioned table in the
Commands book.
> And for element updates (particularly in USERMODs), what support is
> there for an update utility more welcoming of diversity of attributes
> than IEBUPDTE, such as /bin/patch?
Currently there is support only for IEBUPDTE with ++SRCUPD and ++MACUPD
(and also jar file updates using the java jar command and ++JARUPD, but
thats another topic).
Kurt Quackenbush -- IBM, SMP/E Development
gil...@ibm-main.lst
> Date: Sun, 12 Sep 2004 19:55:35 -0300
>
> In <41447F24...@phoenixsoftware.com>, on 09/12/2004
> at 09:53 AM, "Edward E. Jaffe" <edj...@PHOENIXSOFTWARE.COM> said:
>
> >If FBA support in MVS was easy, it would have been done a long time
> >ago.
>
> Every time someone says "I don't believe in theories" another theory
> dies. Everything that I've seen suggests that the decision was based
> on IBM inernal politics rather than technical difficulty.
>
Clarke's First Law again, isn't it? (And maybe the second.)
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
gil...@ibm-main.lst
> Date: Sun, 12 Sep 2004 20:11:25 -0300
>
> There is no standard Unix SPOOL method.
>
Doesn't need one. The basic UNIX filesystem was always sufficient
to the needs of spooling?
Is there a standard OS SPOOL method?
> >There would have to be an FBA oriented tape access method
>
> Why?
>
There is some deficiency in ability to access tapes via
Unix Services. Particularly, it's ironic that the Unix
Services implementation of "tar", which was originally
the acronym of Tape ARchive, doesn't provide access to
archives on tapes. As I said earlier, device drivers can
solve many such problems. In this case, I'd accept that
the ROI doesn't justify providing such a driver. I've
generated tar archives on tape by piping through IEBGENER.
Shmuel Metz , Seymour J.
at 08:31 AM, Paul Gilmartin <gil...@UNIX.STORTEK.COM> said:
>Is there a standard OS SPOOL method?
FSVO. There's support in both JES2 and JES3 to access SPOOL files via
an ACB, and there's a CI to convert DCB-based access to RPL based. The
way in which files are stored on the SPOOL and the way in which the
JES manipulates SPOOL data are strictly internal to the JES; there is
no common format or common service.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
gil...@ibm-main.lst
> Date: Mon, 13 Sep 2004 12:22:58 -0300
>
> >I hope with the provision that USASCII should be enthusiastically
> >supported.
>
> Why? It's an anachronism. The future is Unicode.
>
I largely agree. If Unicode in the UTF-8 representation,
of which USASCII is a subset, were enthusiastically supported,
I'd deem that as enthusiastic support of USASCII.
I would not consider UTF-EBCDIC as providing such enthusiastic
support.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Steve Comstock
> In a recent note, "Shmuel Metz (Seymour J.)" said:
>
>
>>Date: Mon, 13 Sep 2004 12:22:58 -0300
>>
>>
>>>I hope with the provision that USASCII should be enthusiastically
>>>supported.
>>
>>Why? It's an anachronism. The future is Unicode.
>>
>
> I largely agree. If Unicode in the UTF-8 representation,
> of which USASCII is a subset, were enthusiastically supported,
> I'd deem that as enthusiastic support of USASCII.
>
> I would not consider UTF-EBCDIC as providing such enthusiastic
> support.
>
> -- gil
me the only way to go, long term, is UTF-32. Wastes
a lot of memory but never have complex algorithms
checking how many bytes the current character takes
up or if surrogate characters are involved, etc.
I thought it would be cool for IBM to build a new OS
that is 64-bit, UTF-32 based right from the ground up,
using all the knowledge built up from years in the
business. All control blocks supporting 64-bit addresses
and 64-bit integers, all message texts being in UTF-32,
and so on.
But business case, business case...
Kind regards,
-Steve Comstock
gil...@ibm-main.lst
> Date: Mon, 13 Sep 2004 17:48:10 -0300
>
> >Of course Unix, Windows, Netware, VMS also have spool, however don't
> >have neither "spool access method" nor other
> >cylinder-track-gap-vtoc-vvds-ICF-etc. technologies.
>
> Instead, they have a plethora of libraries that are neither compatible
> nor interoperable with each other, to do what would be done with a
> small number of access methods on the mainframe.
>
Alas, z/OS has allowed itself to be infected with this same
disease. When the need for directory entries longer than eight
characters arose, instead of allowing longer names in PDSE
directories (one of the first questions that came to my mind
when I heard there was a new library format was, "Does it
support longer member names?"), z/OS invented the @@DC370$
kludge, and the archive library kludge.
OS was once elegant. z/OS has succumbed to the "plethora of
libraries". This reinforces Clark F. Morris Jr.'s plaint
about short names earlier in this thread:
URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0409&L=ibm-main&D=1&O=D&P=82218
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Edward E. Jaffe
>... When the need for directory entries longer than eight
>characters arose, instead of allowing longer names in PDSE
>directories (one of the first questions that came to my mind
>when I heard there was a new library format was, "Does it
>support longer member names?"), z/OS invented the @@DC370$
>kludge, and the archive library kludge.
>
>
PDSE supports member names of up to 1024 characters in length. (See the
DESERV interface.) We have code that leverages this capability.
--
-----------------------------------------------------------------
| Edward E. Jaffe | |
| Mgr, Research & Development | edj...@phoenixsoftware.com |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
-----------------------------------------------------------------
gil...@ibm-main.lst
> Date: Mon, 13 Sep 2004 17:16:23 -0700
> PDSE supports member names of up to 1024 characters in length. (See the
> DESERV interface.) We have code that leverages this capability.
>
Neat! I had been unaware of that. But now I'm mystified: why do I get:
SDSF OUTPUT DISPLAY SPPGJOB JOB02944 DSID 2 LINE 0 COLUMNS 01- 132
********************************* TOP OF DATA **************************
10.57.36 JOB02944 ---- TUESDAY, 14 SEP 2004 ----
10.57.36 JOB02944 IEF452I SPPGJOB - JOB NOT RUN - JCL ERROR
10.57.36 JOB02944 $HASP396 SPPGJOB TERMINATED
- 0.00 MINUTES EXECUTION TIME
1 //SPPGJOB JOB 505303JOB,'Paul Gilmartin',MSGLEVEL=(1,1),REGION=0M JOB02944
2 //USERC OUTPUT JESDS=ALL,DEFAULT=YES,CLASS=R
//*
3 //STEP EXEC PGM=IEFBR14
4 //SYSUT1 DD DISP=(,CATLG),UNIT=SYSALLDA,SPACE=(TRK,(1,,1)),
// DSNTYPE=LIBRARY,DSN=FOO.BAR(NINEBYTES)
STMT NO. MESSAGE
-
4 IEF642I EXCESSIVE PARAMETER LENGTH IN THE DSNAME FIELD
******************************** BOTTOM OF DATA ************************
.. ? And is 1024 adequate? I read an IBM developer's plaint that C++
requires at least 2048
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Edward E. Jaffe
>In a recent note, Edward E. Jaffe said:
>
>
>
>>Date: Mon, 13 Sep 2004 17:16:23 -0700
>>PDSE supports member names of up to 1024 characters in length. (See the
>>DESERV interface.) We have code that leverages this capability.
>>
>>
>>
>Neat! I had been unaware of that. But now I'm mystified: why do I get:
>
> // DSNTYPE=LIBRARY,DSN=FOO.BAR(NINEBYTES)
> STMT NO. MESSAGE
> -
> 4 IEF642I EXCESSIVE PARAMETER LENGTH IN THE DSNAME FIELD
>
>
PDSE supports long names. JCL does not.
>... ? And is 1024 adequate? I read an IBM developer's plaint that C++
>requires at least 2048
>
>
IBM may have raised the limit when I wasn't looking. Our exploitation
uses only 64 character member names.
--
-----------------------------------------------------------------.
| Edward E. Jaffe | |
| Mgr, Research & Development | edj...@phoenixsoftware.com |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
'-----------------------------------------------------------------'
Ray Mullins
scheduling built in.)
> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@BAMA.UA.EDU] On Behalf Of Edward E. Jaffe
> Sent: Tuesday 14 September 2004 10:12
>
> Paul Gilmartin wrote:
>
> >In a recent note, Edward E. Jaffe said:
> >
> >>Date: Mon, 13 Sep 2004 17:16:23 -0700
> >>PDSE supports member names of up to 1024 characters in length. (See
> >>the DESERV interface.) We have code that leverages this capability.
> >>
> >>
> >>
> >Neat! I had been unaware of that. But now I'm mystified:
> why do I get:
> >
> > // DSNTYPE=LIBRARY,DSN=FOO.BAR(NINEBYTES)
> > STMT NO. MESSAGE
> > -
> > 4 IEF642I EXCESSIVE PARAMETER LENGTH IN THE DSNAME FIELD
> >
> >
>
> PDSE supports long names. JCL does not.
And DYNALLOC doesn't support long names, either, just in case you want
to try it.
> >... ? And is 1024 adequate? I read an IBM developer's
> plaint that C++
> >requires at least 2048
>
> IBM may have raised the limit when I wasn't looking. Our
> exploitation uses only 64 character member names.
Last I checked, it was still 1023, and is currently (as of z/OS 1.2)
only exploited by the binder in creating program objects from GOFF
format (as aliases). If you roll your own DESERV GET_ALL, and point it
to one of the CICS TS load libraries, you can see the long names (like
"/usr/bin/stuff").
An ISPF browse won't show them. I don't remember if a IEHLIST LISTPDS
shows them.
Later,
Ray
--
M. Ray Mullins
Roseville, CA, USA
http://www.the-bus-stops-here.org/
Cat Herder Software (SISS-TEM)
Edward E. Jaffe
>>>... ? And is 1024 adequate? I read an IBM developer's
>>>
>>>
>>plaint that C++
>>
>>
>>>requires at least 2048
>>>
>>>
>>IBM may have raised the limit when I wasn't looking. Our
>>exploitation uses only 64 character member names.
>>
>>
>
>Last I checked, it was still 1023, and is currently (as of z/OS 1.2)
>only exploited by the binder in creating program objects from GOFF
>format (as aliases). If you roll your own DESERV GET_ALL, and point it
>to one of the CICS TS load libraries, you can see the long names (like
>"/usr/bin/stuff").
>
>
It's 1024. See
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d430/3.8.1.2
>An ISPF browse won't show them. I don't remember if a IEHLIST LISTPDS
>shows them.
>
>
Old BPAM (for PDS) supports only 8 character names. So any code locked
into PDSE's BPAM simulation will be limited to 8. To truly exploit PDSE
(as we do), DESERV must be used for the directory interface. Since
DESERV works equally well for PDS, there's no rationale for sticking
with old BPAM services unless you want to be forever tied to the
capabilities (or lack thereof) of the lowest common denominator ... aka PDS.
When I first started researching this subject in preparation for our
conversion effort, I was surprised at the extent to which ISPF was *not*
updated to support PDSE's enhanced capabilities. The developers did the
absolute minimum needed to make it work. IMHO more should be done.
--
-----------------------------------------------------------------.
| Edward E. Jaffe | |
| Mgr, Research & Development | edj...@phoenixsoftware.com |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
'-----------------------------------------------------------------'
Ray Mullins
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@BAMA.UA.EDU] On Behalf Of Edward E. Jaffe
>
> Ray Mullins wrote:
>
> >>>... ? And is 1024 adequate? I read an IBM developer's
> >>>
> >>>
> >>plaint that C++
> >>
> >>
> >>>requires at least 2048
> >>>
> >>>
> >>IBM may have raised the limit when I wasn't looking. Our
> exploitation
> >>uses only 64 character member names.
> >>
> >>
> >
> >Last I checked, it was still 1023, and is currently (as of z/OS 1.2)
Finger check. It is 1024 for the name and the binder does support 1024
for aliases for whatever reason (base entries still need to be 8
character members).
Looking at _Program Management_, the binder now supports entry name
length of 32767. Hmmmm.....
It would be nice if EXEC PGM='/path/name' was supported; then contents
management could search for the path name specified as an alias in a
STEPLIB or something in the search chain.
> >only exploited by the binder in creating program objects from GOFF
> >format (as aliases). If you roll your own DESERV GET_ALL,
> and point it
> >to one of the CICS TS load libraries, you can see the long
> names (like
> >"/usr/bin/stuff").
>
> It's 1024. See
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt
> 2d430/3.8.1.2
>
> >An ISPF browse won't show them. I don't remember if a
> IEHLIST LISTPDS
> >shows them.
>
> Old BPAM (for PDS) supports only 8 character names. So any
> code locked into PDSE's BPAM simulation will be limited to 8.
> To truly exploit PDSE (as we do), DESERV must be used for the
> directory interface. Since DESERV works equally well for PDS,
> there's no rationale for sticking with old BPAM services
> unless you want to be forever tied to the capabilities (or
> lack thereof) of the lowest common denominator ... aka PDS.
I added the code to support long names for Software AG's Entire System
Server, for both read and update for program objects. One nice thing
about DESERV is that you can read the entire directory into memory at
once and not worry about people screwing around with the directory
underneath you.
> When I first started researching this subject in preparation
> for our conversion effort, I was surprised at the extent to
> which ISPF was *not* updated to support PDSE's enhanced
> capabilities. The developers did the absolute minimum needed
> to make it work. IMHO more should be done.
Me, too. At least implement read-only support.
I wonder if IBM supplies anything now that encapsulates DESERV in a
futility.
Later,
Ray
--
M. Ray Mullins
Roseville, CA, USA
http://www.the-bus-stops-here.org/
Cat Herder Software (SISS-TEM)
----------------------------------------------------------------------
Edward E. Jaffe
>Looking at _Program Management_, the binder now supports entry name
>length of 32767. Hmmmm.....
>
>
I noticed that too. It's possible that DESERV was enhanced to support
lengths beyond 1024, but the doc was never updated to reflect that. Can
anyone (at IBM or otherwise) confirm this?
[snip]
>I wonder if IBM supplies anything now that encapsulates DESERV in a
>futility.
>
>
Futility? Is this a Freudian slip?
--
-----------------------------------------------------------------
| Edward E. Jaffe | |
| Mgr, Research & Development | edj...@phoenixsoftware.com |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
-----------------------------------------------------------------
----------------------------------------------------------------------