Re: Doubtful list etiquette (Should have been: USS misuse again, Was: HFS file questions)

>I am reminded once again of the pitfalls of attempting >written humor with an international audience. How embarrassing. You got me. We use to say that a joke that has to be explained is no longer funny. However, you just proved that this does not hold true in every case. I'm still smiling about

Re: /tmp space is full

>(I seem to vaguely remember that some PFS types have got >some dependency on that name in never releases. I know the >above worked in earlier OS/390 releases; I tried) For the records: I've been searching my old notes and found that - ZFS must be ZFS. You'll get a message from ZFS when you t

Re: LINKLIB in use / Darwin

I'm not sure I noticed the original append in this thread, but just to re-iterate what has been stated by those who responded, and often in the archives: It is likely NEVER safe to delete a data set that is within an in-use LNKLST set, The (SETPROG, PROGxx) LNKLST UNALLOCATE function is provi

Re: What is "address spec terminates" in context of LOAD EOM=YES?

To answer the original question: End of Memory is end of memory. There is no ambiguity. End of memory is not limited to "force" which could be considered "abnormal" end of memory. To any user of LOAD with GLOBAL=YES, whether it allows deletion of the module at task termination of the requesto

Re: What is "address spec terminates" in context of LOAD EOM=YES?

>But a directed LOAD followed by an >appropriate IDENTIFY macro will achieve the same result in a shorter >path length. There is no documented use of IDENTIFY that performs this function. All documented uses of IDENTIFY work on an already-created CDE (possibly LPDE too, I can't remember). Direct

Re: Doubtful list etiquette (Should have been: USS misuse again, Was: HFS file questions)

A friend posted he had Chia balls for supper. I replied hoping he did not come down with an intestinal blockage from the clay center. On Sun, Feb 13, 2011 at 5:27 PM, Rob Schramm wrote: > Jim, > > I really should have caught that reference.  I love "Big Bang Theory".  I > wonder what Dr. Sheldon

Re: Doubtful list etiquette (Should have been: USS misuse again, Was: HFS file questions)

Jim, I really should have caught that reference. I love "Big Bang Theory". I wonder what Dr. Sheldon Cooper would say? ;-) Probably that he should decide any such weighty matters. And that mere systems programmers are below engineers. ;-) Rob On Sun, Feb 13, 2011 at 3:15 PM, Jim Mulder wro

Re: Doubtful list etiquette (Should have been: USS misuse again, Was: HFS file questions)

On 2/13/2011 3:15 PM, Jim Mulder wrote: I will attempt to control my obsession with obscure referential humor. For a while, at least. Perhaps we can shift the discussion to why IBM is misusing RAMAC? Gerhard Postpischil Bradford, VT ---

Re: Doubtful list etiquette (Should have been: USS misuse again, Was: HFS file questions)

IBM Mainframe Discussion List wrote on 02/13/2011 08:48:13 AM: > I'd really love to understand why on earth people like you are defending > that term in the name of VTAM. You won't change this anymore, like nobody > else will. "USS" has become the defacto standard name for z/OS UNIX System > S

Re: HFS file questions

>Are you suggesting that I leave this list and go there? No, definitely not! Others have already guesed what I wanted to suggest you. I apologize for having been to lazy to add another sentence or two. -- Peter Hunkeler Credit Suisse -

Re: Using CTTSBD of Control-T to migrate volumes

Thanks, Customer demand that the copies will not be stacked (my opinion that he has justified reasons). any chance that you know how not to stack ( I mean which parameters should be used) ? Thanks again, Arye. On 13 February 2011 19:45, af dc wrote: > Hi Arye, > We used it to copy STK virtua

Re: ISPPROF DISP=?

Binyamin Dissen wrote: >DISP=SHR conflicts with DISP=OLD. If the user has DISP=OLD, DISP=SHR will >fail. >Will not help if the user has DISP=OLD. What about a new 'holy grail' keyword: DISPose? Oops ... ;-D Did the OP found his solution? Or did I missed it somewhere? I'm asking because I'

Re: Using CTTSBD of Control-T to migrate volumes

Hi Arye, We used it to copy STK virtual tapes to IBM logical volumes but using stacking. MDB and ICF catalog updated. A.CEcilio On Tue, Feb 8, 2011 at 7:43 AM, Arye Shemer wrote: > Hello forummers, > Has anyone had experience with CTTSBD utility of CONTROL-M/T to copy volumes > (not stacking just

Re: HFS file questions

In <1809672709-1297553434-cardhu_decombobulator_blackberry.rim.net-7009219...@bda2487.bisx.prod.on.blackberry>, on 02/12/2011 at 11:30 PM, Ted MacNEIL said: >arogant PKB >Grow up! Physician, heal thyuself! -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see

Re: Subject headers changing in IBM-MAIN

In , on 02/11/2011 at 02:35 PM, Elardus Engelbrecht said: >I waited for your kind reply because you are an expert on those RFC >things. I also saw other excellent replies especially that posts >from Bill Godfrey. Yes; I only gave an analysis of the symptoms but he went a step further and tr

Re: Is there a way to have SMPE indicate if an LMOD is changed?

On 2/12/2011 4:16 PM, Skip Robinson wrote: We have VPS but not DRS. Let me describe the problem I'd like to solve. Can't you write the SMPDATA1 output to disk and then add a step to read the disk file and write it to sysout? -- Richard -

Re: Is there a way to have SMPE indicate if an LMOD is changed?

Could your REXX step read either the SMPOUT report from the SMP/E step with SDSF or read the SMP/E log? Bob Skip Robinson wrote: We have VPS but not DRS. Let me describe the problem I'd like to solve. GDPS is not currently orderable in ServerPac, so we install it in its own CSI. I need a sim

Re: ISPPROF DISP=?

On Fri, 11 Feb 2011 09:08:46 -0700 Steve Comstock wrote: :>On 2/11/2011 8:59 AM, Jeff Holst wrote: :>> I ran into an issue recently when testing the Fault Analyzer GUI. One of its :>> functions causes the Fault Analyzer GUI server to try to read a member if the :>> user's ISPF profile data set.

Re: Doubtful list etiquette (Should have been: USS misuse again, Was: HFS file questions)

>Perhaps some form of hybrid acronym like zUSS >could serve as being both highly compact and descriptive, while >avoiding potential confusion with prior art. Jim, As much as I do respect you, I can't agree with that suggestion. z/OS' Health Checker compontent has chosen to name its z/OS UNIX