|
View previous topic :: View next topic
|
| Author |
Message |
Mamata Patel
New User
Joined: 08 Apr 2010
Posts: 2
Location: Bangalore
|
|
|
|
Please help me to get the exact reason of below question.
why we will create the load module in PDS only, why not in PS data set?
Thanks in Advance. |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
because the whole thing was designed this way!
99% of the times the why is ...
see the first line  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello and welcome to the forum,
Because modules are executed from "load libraries" which contain additonal information about the modules.
Also, simple arithmetic. . . Better to keep track of 1 pds with 5,000 modules than 5,000 files . . . |
|
| Back to top |
|
|
Mamata Patel
New User
Joined: 08 Apr 2010
Posts: 2
Location: Bangalore
|
|
|
|
| Thanks for ur reply. if have only one module eventhough we will use PDS only why?. I want specific reason. |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
| Mamata Patel wrote: |
| I want specific reason. |
You've got 2 very good reasons already. Why do you want more? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
| Quote: |
| I want specific reason. |
again only the system designers can tell You the reason 
when You design something from scratch what are the reasons for one choice rather than another one?
an external mind can only guess!
for load modules the reason to use PDS is hidden in a much higher design document
same applies to why some BINDER object ( load modules ) MUST be stored in a PDSE |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Long long ago programs were run by reading in a (with a card reader)
deck of binary punch cards. After that one could put those decks (for different programs on tape and by means of label processing choose
a program to run (GE-400 series i worked with). Then the same could be done by putting the programs on disk. Since VSAM was not invented yet
(if yes maybe that was chosen) the PDS was invented.
Previous story i told my kids to get to sleep.
And hey it was working. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
| Quote: |
| (GE-400 series i worked with) |
the GECOS was a great operating system
too bad that I threw away quite a few manuals |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Quote: |
the GECOS was a great operating system
too bad that I threw away quite a few manuals
|
Same here. It was great fun working with the GE-437. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
| not even the interviewer knows ! |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| enrico-sorichetti wrote: |
| not even the interviewer knows ! |
Just old hands like you and me.
I even worked with the gamma-30. Programmed in French.
Branchez a droit/gauche instructions.
Pupitre = console.
That was really nice. |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| enrico-sorichetti wrote: |
| because the whole thing was designed this way! |
| dick scherrer wrote: |
Because modules are executed from "load libraries".
Also, simple arithmetic. . . Better to keep track of 1 pds with 5,000 modules than 5,000 files . . . |
Please don't forget that DOS was here before OS and, in some small way, PDSs do seem to resemble core, relo and source libs....grin.... |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
I worked at something even better...
the ELEA 6001 from OLIVETTI Italy
DECIMAL repeat DECIMAL machine with memory sizes in increment of 10000 <things>
with a COBOL compiler in ITALIAN
smart machine... everything was variable length...
the <byte> was made of the 4 (IIRC) data bits,parity bit, stop bit
the storage address in the machine instruction was reversed
so that the high order digits were taken from the previous instruction
there was no need to specify the operands lengths because it was determined by the stop bit
the registers were simply a storage location addressed as registers
to <save> the registers You did not have to save them, it was enough to point the register area to a different storage address |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Jees Enrico,
you are that old?  |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
| Quote: |
| DECIMAL repeat DECIMAL machine with memory sizes in increment of 10000 <things> with a COBOL compiler in ITALIAN |
Our decimal machine (Burroughs 200/300 series) had only 4.8k of fixed-length "things" - we'd have sold our soul for 10k - let alone multiples of 10k. . .
No COBOL - only assembler. Neither tape nor disk - cards in, cards or paper out.
And this was the 3rd "stored program" computer i worked on (before that wired panels). . .
| Quote: |
| Please don't forget that DOS was here before OS and, in some small way, PDSs do seem to resemble core, relo and source libs....grin.... |
Once upon a time it was told that OS was supposed to be "up and running" before there was a DOS and that DOS was put together and released to keep this computing environment (s360 and subsequent) moving forward. Back then were many hardware choices and IBM surely did not want to be left out due to Operating System problems as the move from tabulating machines to "real computers" unfolded.
d |
|
| Back to top |
|
|
MBabu
Active User
Joined: 03 Aug 2008
Posts: 400
Location: Mumbai
|
|
|
|
| Neither of the two answers (it is what it is because it is, and because it is, so there) are answers to the question. The reason is that you can't use a PS directly is that there is metadata associated with executables that is stored in the PDS or PDSE directory. The load process uses the directory to determine things like amode, rmode, execute vs no-execute, etc. A PS does not have a place to store that metadata. Why would it be designed that way? Probably because reading a PDS directory is very fast as opposed to opening a sequential data set for each load module just to determine its attributes. Also, the system can cache TTRs (physical locations from which to read the module) quickly. I don't know why it was designed the way it was, but the reason you can't use a PS is the data in the directory. Its the same reason that you can't copy a load module (w/o the directory) to a PS and expect it to ever work again. As mentioned, you can store unlinked object in a PS and the loader can handle that but that is not a load module. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
| Quote: |
Neither of the two answers (it is what it is because it is, and because it is, so there) are answers to the question. The reason is that you can't use a PS directly is that there is metadata associated with executables that is stored in the PDS or PDSE directory.
|
| Quote: |
| I don't know why it was designed the way it |
so You do not know the answer either
why the metadata is stored in the pds directory ?
why...
why...
repeat with me ... because of the design,
so the only people who know the real reason are those who designed the whole thing
You are giving as a why the details of the implementation ( meatadata <stuff> )
but that' s not a reason just the visible part of the design |
|
| Back to top |
|
|
MBabu
Active User
Joined: 03 Aug 2008
Posts: 400
Location: Mumbai
|
|
|
|
with all due respect, that is silly. no one asks a question so that they can be told 'because it is that way'. Questions are asked because people want useful information. The question implies a search for the reason behind the design. The 'thats the way it is designed' answer is just like asking a doctor "why am I sick" and getting the response "because you aren't healthy". Its useless, pointless, and insulting, and appears to be intended to be degrading.
I have to say that the whole tenor of this board is one of people answering questions with pointless, insulting responses. Just like the history of the other mainframe boards, it appears to be experienced people who want to keep their hand in the mainframe game, but are upset that jobs are moving to India or elsewhere so they treat the new people, those asking questions, as the enemy, and as idiots.
No - I don't know the reason for the original design. But I do know the consequences of doing what the question asks about. If speculating on the reason for the design is bad then call me wicked. But at least I'm not going to insult the intelligence of the original poster. |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
@MBabu -
Apart from a full explanation from the original designers, I think that your explanation is most reasonable.
It should be apparent to any programmer worthy of the title that opening/reading/processing ( a set of ) PDS/PDSE directories is leaps and bounds faster than opening/reading/processing each and every physical sequential file that the directory entries represent in order to derive the needed information ( e.g. how much storage to GETMAIN in order to bring a load module into core, where to load it ( above/below the line), etc. ). Directories also facilitate the use of concatenated libraries and the use of member aliases. Think of what it would be like to do that with PS files - without degrading both performance and maintenance ( Imagine what hoops would have to be jumped thru for LNKLIST or a CICS PCT without the use of PDS/PDSE's ). Ewww. Wouldn't want to go there. |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| MBabu wrote: |
| with all due respect, that is silly. no one asks a question so that they can be told 'because it is that way'. Questions are asked because people want useful information. The question implies a search for the reason behind the design. The 'thats the way it is designed' answer is just like asking a doctor "why am I sick" and getting the response "because you aren't healthy". Its useless, pointless, and insulting, and appears to be intended to be degrading. |
Not really, there are many things in the IBM MF world that are as they are because of the original design and the need to keep compatibility across multiple OS versions. Sometimes the only reasonable answer to some of the most idiotic designs is because that is the way it is.....
| Quote: |
I have to say that the whole tenor of this board is one of people answering questions with pointless, insulting responses. Just like the history of the other mainframe boards, it appears to be experienced people who want to keep their hand in the mainframe game, but are upset that jobs are moving to India or elsewhere so they treat the new people, those asking questions, as the enemy, and as idiots.
|
Now this I don't agree with, and it sounds as if you think that a short answer is something personal. Never the less, I don't take your view of 'experienced people' personally, I just assume that your personal view is yours.
| Quote: |
| No - I don't know the reason for the original design. But I do know the consequences of doing what the question asks about. If speculating on the reason for the design is bad then call me wicked. But at least I'm not going to insult the intelligence of the original poster. |
To properly speculate on the reason for some existing design, you have to look back in IBM computing history to the limitations and restraints forced upon those original designers. Unfortunately, I don't think very many of them are members of this forum but if there was somebody with the original knowledge, I hope that they might answer your questions. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
the original question was
| Quote: |
| Please help me to get the exact reason of below question. |
the exact reason is hidden in the design of OS/360
there are too many PDS features that are used only for program management
and it is reasonable to suspect a chicken and egg issue
was the BPAM an aseptic access method or was it designed to support specifically Program management ?
and reading the PLMs I got that impression
the description of the how can be found in the logic manuals published in the sixties
for example
bitsavers.org/pdf/ibm/360/os/plm_1966-67/Y28-6610_LinkEdit_E_PLM_Jun67.pdf
for the linkage editor
a prerequisite for all the data managemnt program logic manuals
bitsavers.org/pdf/ibm/360/os/plm_1966-67/Y28-6605-2_Introduction_To_Control_Program_Logic_PLM_Sep66.pdf
and here is the link to the relevant program logic manuals
bitsavers.org/pdf/ibm/360/os/plm_1966-67/
to be read in order are
introduction to control program logic
job management PLM
I/O supervisor PLM
Sequential_Access_Methods_PLM_Jan67.pdf
odd enough I was not able to find a BPAM PLM
so the reason might be reversed ...
You have to use PDS ( BPAM ) because
1) polite reply
... that was the data <organization> designed/chosen to support the whole program management shebang
2) less polite reply
... because the manual says so
and I am showing much respect because I took time to investigate and research
for a badly posed question
if somebody is curious about linkage editor ways
www.mainframe.eu/mvs38/asm/
www.mainframe.eu/mvs38/asm/Linkage%20Editor%20%28HEWL%29/ |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
Thanks for the pointers....
| Quote: |
| and reading the PLMs I got that impression |
Jeez, I haven't handled a PLM since Rel 24 (or was it 21?) and they were (even as they became less accurate and more obsolete as each new release was distributed) a great insight to the OS and allowed us in the trenches to do some initial debugging before having to call the people (at that time they were idiots if you did not have the symptoms to match their keyword lookup) at level one support...... |
|
| Back to top |
|
|
|
|
