|
View previous topic :: View next topic
|
| Author |
Message |
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| Randy Horowitz wrote: |
Steve,
O.K. so never got an answer to my question but it was an interesting conversation. Thanks for the work arounds. Funny my thought was that a concatenation is still one ddname and the Conversion/Interpreter leads me to think that more that one dsname concatenated in one ddname would mean that they would be multiple dsname keys. |
Oh, you're probably thinking
alloc file(ddnamw) dataset(dataset1 dataset2 ...)
What internally happens is the alloc command allocates each data set as a separate DD statement and then concatenates the DD statements. |
|
| Back to top |
|
 |
Randy Horowitz
New User
Joined: 06 Feb 2018
Posts: 18
Location: United States
|
|
|
|
How would
//STEPLIB DD DSN=HLQ.LIB1,DISP=SHR
// DD DSN=HLQ,LIB2,DISP=SHR
// DD DSN=HLQ.LIB3,DISP=SHR
// DD DSN=HLQ.LIB4,DISP=SHR
come in the buffer ?
I think the DSNs would be a number of X'4A' key with the number of parms=4
or would it be a number of X'4A' entries ? |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
The question, as posed, is meaningless. Each DD statement is presented to exit 6 as an entity. The mechanics of how the internal text is built is none of our business. Exit 6 sees the internal text for 4 DD statements. There is no such thing as a 4A key with 4 data set names.
//STEPLIB DD DSN=HLQ1.LIB1,DISP=SHR
then
// DD DSN=HLQ.LIB2,DISP=SHR
and so on. Remember this whole business started so HASP could change SYSOUT=A to UNIT=xxx. I no longer remember what the xxx was, but the purpose was so MVT would actually allocate a pseudo printer that HASP would intercept I/O intended for the printer and write it to its SPOOL.
When you write a program that uses QSAM, do you try to access the I/O buffer as an entity? No, because the precise structure of the I/O buffer varies from data set to data set. QSAM, on purpose, hides this from you so your code can be kept simple. If you think you need to access an entire I/O buffer at a time you use BSAM. If you do it right you save some CPU time, though in the long term the cost is program complexity. Most of the time it's done wrong, which costs program reliability or imposes unnecessary program restrictions or both. In fact it appears to be taught wrong, to simplify the training text. |
|
| Back to top |
|
|
Randy Horowitz
New User
Joined: 06 Feb 2018
Posts: 18
Location: United States
|
|
|
|
| Thank you very much for your comments. |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
| Randy Horowitz wrote: |
| These are jobs that come out of a scheduler, no one is going to dynamically allocate anything, they are COBOL batch jobs. We want to prevent a user from executing a load module from an "unapproved" loadlib. |
Just a thought: wouldn't it be easier to check the JCL (once) while/before it is added to the scheduler, instead of checking it every time it is submitted by said scheduler ? |
|
| Back to top |
|
|
Randy Horowitz
New User
Joined: 06 Feb 2018
Posts: 18
Location: United States
|
|
|
|
| Yes, of course ! All of the sane arguments were made. This is a last ditch effort to please the auditor's in a shop gone crazy !! Please a little understanding here. All logic has flown out the window. Who for god sakes does not protect the schedule library ? I am the only one on staff who knows assembler so I get called into to do it. I am a CICS guy, I couldn't care less about JES2 or its exits. I have my own exits in CICS to worry about. Thanks ! |
|
| Back to top |
|
|
|
|
