Re: LAE instruction
John McKown wrote: > If you want to copy the contents of AR4 into AR3, you can do it if you have a > "free" register with two instructions: EAR R?,R4; SAR R3,R? . Or you could just use CPYA AR3,AR4. No "free" register required. Regards, Allen Gainsford Info Developer, Banking Shared Services HP Enterprise Services (South Pacific) Office +64-4-819-5236 | Fax +64-4-819-5955 | Email allen.gainsf...@hp.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: bpxwdyn rc = 4294967263
> All: > > I am testing a BPXWDYN call in Cobol and I am building this allocate... > > ALLOC DD(TEMPFLE) DA(PIONEER.TEST.SYSIN) NEW CATALOG UNIT(SYSDA) CYL > SPACE(1,1) DSORG(PS) > RECFM(F) LRECL(80) > > I have tied with and without BLKSIZE(80) and in either situation see a > 4294967463 return > code > Do I assume the class code is 4 and the error is x'294' ...?? 4294967463 is hex 100A7. So if you ignore the high-order fullword, I'd suggest that you got a return code of 167. Regards, Allen Gainsford Info Developer, Banking Shared Services HP Enterprise Services (South Pacific) Office +64-4-819-5236 | Fax +64-4-819-5955 | Email allen.gainsf...@hp.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: COBOL execs Dummy Question
> IGYCRCTL is the executable load module that is the Resident Control phase > (main program) of the COBOL compiler. > > Now my turn...how does this information help you? Satisfaction of his curiosity? :) I too was interested to see the derivation of the name. Personally, any time I see "IGYCRCTL" I think to myself, "Iggy Cricktill". Not sure why I feel compelled to pronounce the name rather than just spelling it out! Regards, Allen Gainsford Info Developer, Banking Shared Services HP Enterprise Services (South Pacific) Office +64-4-819-5236 | Fax +64-4-819-5955 | Email allen.gainsf...@hp.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: I thought it would be easy (IEBDG)
> Let's take a simplified example. > I want to create a file with a 2 byte record with x'a1b2' as the contents. > > I use FD to define two fields, each one byte long: > FD NAME=BYTE1,LENGTH=1,STARTLOC=1,PICTURE=161 > FD NAME=BYTE2,LENGTH=1,STARTLOC=2,PICTURE=178 IEBDG definitely isn't an easy way to do it, but if you really want to use it, then the following works: FD NAME=BYTE1,LENGTH=1,STARTLOC=1,PICTURE=3,B'161' FD NAME=BYTE2,LENGTH=1,STARTLOC=2,PICTURE=3,B'178' CREATE QUANTITY=1,NAME=(BYTE1,BYTE2) Regards, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: "Underscore" character
John Gilmore writes: > Mr Altmark is again only marginally correct about the term > 'underscore', as the OED quotations for it make clear, it is a > slightly antique term used literally. The OED defines "underscore", among other meanings, as: "a key on a computer or typewriter keyboard which produces a short horizontal line on the baseline." Is this somehow unclear? It certainly does not seem "antique". > The response it elicited from Mr Altmark requires another sort of > comment. Its tone is magisterial. Its content is radically > inadequate. He should do his homework before he ventures another > such. I shall not be so polite next time. For Mr Gilmore to accuse anyone else of taking a "magisterial" tone is truly hilarious. Allen Gainsford Info Developer, Banking Shared Services HP Enterprise Services (South Pacific) Office +64-4-819-5236 | Fax +64-4-819-5955 | Email allen.gainsf...@hp.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: "Underscore" character
> Regrettably, their forceful expression does not endow Mr Gainsford's > views with substantive merit. The OED defines the verb to underscore > as > > to draw a line or score underneath, to underline > > The character '_' does not have this function. It cannot indeed be > used in this way. To call it an underscore is thus at once incorrect > and rather silly. It is of a piece with Mr Gainford's misuse of the > word 'anachronistic'. The underscore character does indeed have this function, and has been used in this way countless times, on a device called a typewriter. As others have pointed out, it has also been used this way, countless more times, on overprinted lines of computer printout. The fact that underscoring with a typewriter or a printer is now nearly a thing of the past (thus making it, in fact, anachronistic) in no way invalidates the name "underscore". Allen Gainsford Info Developer, Banking Shared Services HP Enterprise Services (South Pacific) Office +64-4-819-5236 | Fax +64-4-819-5955 | Email allen.gainsf...@hp.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Security is fun in the PC world....
> Didn't Bill Gates once say "We are not going to make the same mistakes > those folks in the mainframe world did"? According to Bob Bemer, it was Ted Nelson who said it. http://www.bobbemer.com/INSIDE-A.HTM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL: IF and ABEND
Schwarz, Barry A said: > > Have you considered splitting it into two jobs. The first job would have > everything up to the "particular" step followed by a step with COND=EVEN to > submit the second job. The second job would not need any special JCL since > any > of its steps that abend would cause the remaining steps to flush. Yup, I've thought about it. But it adds a level of complexity to the system that I'd rather avoid if possible. I'm looking for a simpler way. At this stage I'm starting to think that the simpler way may not exist, and I may have to either live with the situation, or go with the complex way... Cheers, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL: IF and ABEND
Donald Johnson said: > > Allen, based on your example, if you leave your IF statement as is, and code > STEPC and STEPD with ,COND=(0,NE) then if A gets the U0111, the steps inside > the IF/ENDIF are executed. If B then abends or returns anything other than > 0, C and D are flushed. > > I think we can easiy use a combination of COND statements and IF/ENDIF, > leveraging the strengths of each where appropriate. > *don* Nope. I just tried it, adding COND=(0,NE) to all steps. If A abends with U111 and B also abends, C and D still execute. > > //STEPA EXEC PGM=... > > //IF (STEPA.RUN=TRUE OR STEPA.ABENDCC=U0111) THEN > > //STEPB EXEC PGM=... > > //STEPC EXEC PGM=... > > //STEPD EXEC PGM=... > > //ENDIF Cheers, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL: IF and ABEND
Mike Schwab said: > > COND only works with ONLY or EVEN, not a specific abend code. > Have you tried > // IF (proc.step.rc EQ U111) THEN > to see if it works? Yes. Please see my original post. The problem is that if I code: //STEPA EXEC PGM=... //IF (STEPA.RUN=TRUE OR STEPA.ABENDCC=U0111) THEN //STEPB EXEC PGM=... //STEPC EXEC PGM=... //STEPD EXEC PGM=... //ENDIF then, if STEPA abends with U111, STEPB will execute. But if STEPB also abends, then STEPC and STEPD will still execute, even though they're not the subject of the IF. I want a way to force STEPC and STEPD to be flushed if STEPB abends. The only way I've found so far is to surround STEPC and STEPD with their own IF statements, so that STEPC only runs if STEPB explicitly ran and did not abend, and STEPD only runs if STEPC explicitly ran and did not abend. This is long-winded, tedious, and over-complex. But so far I haven't been able to find another way. Regards, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL: IF and ABEND
> Scott Ford said: > > What about this: > //COND2 EXEC PGM=TCOND,PARM=11 > //A > Allen: > > What about this: > //COND2 EXEC PGM=SETCOND,PARM=U111 > //AA SET ABENDCC=U0111 > // IF (COND2.RUN=TRUE OR COND2.&ABENDCC=U0111) THEN > > Scott J Ford I think you've misunderstood. My problem is not with creating a return code; that's very easy. (As I said, we have a trivial utility that does it just fine.) My problem is how to use either IF statements, or CONDs (IF statements preferred), to allow a job to continue if a particular step abends, but to flush remaining steps if any further step abends. Regards, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL: IF and ABEND
> I would like to try this process myself, but don't have a cond code program > that will also set abend codes. Is the source for setcond or sscond > available for me to try this? > *don* > > On Fri, Jun 3, 2011 at 5:20 PM, Paul Gilmartin wrote: > > > On Fri, 3 Jun 2011 16:06:09 -0500, Rick Fochtman wrote: > > > > > >>//COND2EXEC PGM=SETCOND,PARM=U111 > > >>// IF (COND2.RUN=TRUE OR COND2.ABENDCC=U0111) THEN > > >> > > >>//COND2EXEC PGM=SSCOND,PARM=U111 > > >>// IF (COND2.RUN=TRUE OR COND2.ABENDCC=U0111) THEN > > > > >- > > >You keep using PARM= values in your examples. Try looking at the COND= > > >parameter of the EXEC statement. > > > > > What assumptions are you making about the specification of the > > SETCOND and SSCOND programs? > > > > -- gil I beg your pardon. I seem to have mixed SETCOND and SSCOND instead of using SETCOND throughout. Either way, this is a trivial program for setting a desired return code or abend code. It's an internal program and I don't have permission to share code, but it should be trivially easy to duplicate. :) Regards, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL: IF and ABEND
> Hi Allen, > > One package does have the obvious advantage of being - one package. Do you > have > a decent scheduling system, one that can track completion, and > handle predessors and successors, etc.? Ours does. Our p rocesses are set > up > in 'family' groups, for example xxxJ0110, xxxJ0120, xxxJ0130, and so on. ABEND > recovery and restart is generally much simpler wth the smaller jobs in > a family > group. > > Linda Yes, we do have a decent scheduling system (CA7), and I can go the package direction if I have to. I'd rather not, if I can find another way. Cheers, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL: IF and ABEND
> The EVEN subparameter can be used to do what you want to do. > > Its use is a little problematic, but if you read the cautionary languageabout > it > in the JCL manual it should give you no real difficulty. > > John Gilmore Ashland, MA 01721-1817 USA I beg your pardon, but I don't quite see how. The JCL Reference manual seems to me to say that EVEN will allow a step to execute if *any* previous step has abended. I don't see any syntax that allows it to refer to a particular step. In my case I need a step to execute if one particular step has abended, but not if any other step has abended. Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL: IF and ABEND
> > On Thu, Jun 2, 2011 at 5:30 PM, Gainsford, Allen > wrote: > > > Normally (by default), if a jobstep abends, subsequent steps are flushed. > > There ought to be a better way! Have I missed something obvious? Can > > anyone offer a suggestion? > > > > > > can this be managed by breaking the jcl into multiple jobs and posting > conditions to the scheduler and let the scheduling system manage the > process? Yes, but at the cost of making the process even more complex. :) I tend to think that, from a support viewpoint (i.e. from the viewpoint of someone who has to go in and look at job output and possibly trace results), one job is a lot easier to handle than two or three. It's definitely a lot tidier. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
JCL: IF and ABEND
Normally (by default), if a jobstep abends, subsequent steps are flushed. I have a requirement in a job that, if a particular step of the job abends with a particular code, then the job should continue. However, if any subsequent step abends, then further steps should be flushed. This seems unfortunately difficult to arrange. For example: //COND1EXEC PGM=SETCOND,PARM=0 //COND2EXEC PGM=SETCOND,PARM=U111 // IF (COND2.RUN=TRUE OR COND2.ABENDCC=U0111) THEN //COND3EXEC PGM=SETCOND,PARM=8 //COND4EXEC PGM=SETCOND,PARM=U222 //COND5EXEC PGM=SETCOND,PARM=0 //COND6EXEC PGM=SETCOND,PARM=0 // ENDIF Step COND2 abends with U0111, then the job continues. However, then COND4 abends with U0222 ... and yet COND5 and COND6 still run. (Yes, I can see *why* ... but that's no help.) I can't find any easy way to construct the job so that an abend in COND2 will let things continue but an abend in a step after COND2 will flush the rest of the job. The best I've found so far is this, but it's pretty ugly and I don't want to use it if I can possibly help it: //COND1EXEC PGM=SSCOND,PARM=0 //COND2EXEC PGM=SSCOND,PARM=U111 // IF (COND2.RUN=TRUE OR COND2.ABENDCC=U0111) THEN //COND3EXEC PGM=SSCOND,PARM=8 // IF (COND3.RUN AND COND3.ABEND=FALSE) THEN //COND4EXEC PGM=SSCOND,PARM=U222 // ENDIF // IF (COND4.RUN AND COND4.ABEND=FALSE) THEN //COND5EXEC PGM=SSCOND,PARM=0 // ENDIF // IF (COND5.RUN AND COND5.ABEND=FALSE) THEN //COND6EXEC PGM=SSCOND,PARM=0 // ENDIF // ENDIF There ought to be a better way! Have I missed something obvious? Can anyone offer a suggestion? Allen Gainsford === Info Developer, Banking Shared Services HP Enterprise Services (South Pacific) Office +64-4-819-5236 | Fax +64-4-819-5955 | Email allen.gainsf...@hp.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: get filesize in C or Assembler
> Dear group, > > I'm wondering if there is a way to get the size of a > temporary QSAM-Dataset programmatically without opening > and seeking to the end of the file. The program, which > needs the size information is written in C (and so can > call Assembler) and runs in z/OS-Batch. I played around > with fstat() but did not get my results. The best > approach until now seem to me to use CALL ISPLINK and > get via LMDLIST the ZDLSIZE (used Tracks of the Dataset). > But perhaps somebody has a better idea, perhaps I can use > RDJFCB or BPXWDYN to get to my values. > > Thank you so much for your help in former times. > With best regards > Monika You may wish to check out the GETSIZE=YES parameter on the DCBE macro. This will give you an estimate of the number of blocks in the file; you can multiply this by the blocksize for an estimate of the file size in bytes. No idea if this can be used from a C program, alas; and the DCB does have to be opened to get the estimated value. Regards, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Region size
Rick Fochtman write:
> I'd give a case of your favorite beer for an Assember implementation of
> Knuth's Balanced Binary Tree sort, as detailed in his "Sorting and
> Searching" volume.
>
> I wish he'd finish that series ("The Art of Computer Programming").
> After a stellar start, it seems to have died on the vine.
>
> Rick
Not sure if this is a whoosh or not. Volume 4 of The Art of Computer
Programming came out just a month or two ago. Or perhaps I should
say, "Volume 4A", since the full 4th volume is being split into at
least three sub-volumes due to size.
There's a copy sitting on my desk now.
Cheers,
Allen
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Opening a Spanned File for Input Using Assembler
Steve Comstock wrote: >> WTO ' BEFORE OPEN',ROUTCDE=(2),DESC=(7) >> OPEN (INFILE,INPUT,OUTFILE,OUTPUT) > >You need the open options to be in parentheses: > > OPEN (INFILE,(INPUT),OUTFILE,(OUTPUT)) No, you don't. It might (arguably) be good programming style to include the parentheses, but they are not required and the program will assemble just fine without them. Regards, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: If Else JCL question
> the only cond code testing I ever do when writing procs is, > "if it's true, it's through", meaning the step/job won't > execute if the COND is true. Heh. I learned that one as "If true, don't do". Works out the same, and is catchy enough for me to remember it... Allen Gainsford === Info Developer, Banking Shared Services HP Enterprise Services (South Pacific) Office +64-4-474-5133 | Fax +64-4-474-5258 | Email a...@hp.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64 bit mode disabled
On Tue, Nov 30, 2010 at 6:40 PM, michealbutz wrote: >> Hi, >> >> From what I understand running in 64 bit mode (SAM64) you have to run >> disabled does the >> SAM64 instruction do that >> > >From my understanding, a problem state program can run in AMODE 64. I don't >think it is a requirement to run disabled to use AMODE 64. Problem-state programs can definitely run in AMODE 64 without being disabled -- I've written a few that did so. I have a vague memory of reading, here or on the assembler mailing list, that you would need to run disabled if you wanted to branch to code located above the bar. I also have a vague memory that the Wrath of God would probably fall on you anyway if you tried it, disabled or not. Allen Gainsford === Info Developer, Banking Shared Services HP Enterprise Services (South Pacific) Office +64-4-474-5133 | Fax +64-4-474-5258 | Email allen.gainsf...@hp.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EATTR support
> Is this the same feature as "EADSCB=OK" on the DCBE macro? That's the one. > What if you left your DYNALLOC alone and simply added a DCBE when > required? The DCBE isn't a problem (z/OS 1.9 will just ignore the EADSCB flag). But I'm using an RB extension that's set to display any DYNALLOC errors as WTOs. So if I left the DYNALLOC alone then I'd get some unsightly log messages -- which is really what I'm trying to avoid. Cheers, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EATTR support
> Possibly you can look at IHADFA in DFAFEAT8 for DFAEFSEQFOREAS > - Sequential Extended Format supported Could be ... it's set on our 1.11 system but not on our 1.09 system. Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EATTR support
> What's the best (or preferred) way to check if extended attributes > for datasets are supported (i.e. format 8 or 9 DSCBs)? > I'm working on a module that needs to be able to run in multiple > levels of z/OS. It uses dynamic allocation, and if it's running > on z/OS 1.11 I'd like to use the DALEATT attribute (extended > attributes specification); but if on a lower system level, then > I'd need to leave this attribute out. > I can simply check the current system version and omit DALEATT if > it's less than 1.11; but that seems a bit heavy-handed. Is there > a better way to check if DYNALLOC will support DALEATT (other than > simply trying it)? > > Regards, > > Allen Gainsford > === > Info Developer, Banking Shared Services > HP Enterprise Services (South Pacific) Bump. Not sure if anyone saw this the first time around... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
EATTR support
What's the best (or preferred) way to check if extended attributes for datasets are supported (i.e. format 8 or 9 DSCBs)? I'm working on a module that needs to be able to run in multiple levels of z/OS. It uses dynamic allocation, and if it's running on z/OS 1.11 I'd like to use the DALEATT attribute (extended attributes specification); but if on a lower system level, then I'd need to leave this attribute out. I can simply check the current system version and omit DALEATT if it's less than 1.11; but that seems a bit heavy-handed. Is there a better way to check if DYNALLOC will support DALEATT (other than simply trying it)? Regards, Allen Gainsford === Info Developer, Banking Shared Services HP Enterprise Services (South Pacific) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I'm amazed
> Which is more interesting ?-) No question. Especially when the CICS one is really about screwdrivers. :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Creating an I/O error
>> Possibly silly question, but I need to test a SYNAD routine, and I >> can't think of any way to actually produce an I/O >error upon >> command. Can anyone point out any solutions? > >Create a Unix file with lines longer than LRECL; allocate it with >FILEDATA=TEXT and read it. > >With practically any Classic data set, allocate it with overriding >BLKSIZE < size of an actual block; read it. > >Writing is harder. > >-- gil Thanks; worked fine. Cheers, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Creating an I/O error
Possibly silly question, but I need to test a SYNAD routine, and I can't think of any way to actually produce an I/O error upon command. Can anyone point out any solutions? Regards, Allen Gainsford Info Developer, Banking Shared Services HP Enterprise Services (South Pacific) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Safe C++ char array functions (Was " Is there a good mailing list or forum for mainframe C/C++ specifically?")
> Correct on strcpy_s versus strncpy. Strncpy has the possibility of making a > new bad situation while preventing another. You can easily end up with a > string that is guaranteed to "run wild" if you strcpy it. I personally have always preferred strlcpy to strncpy or strcpy_s, since strlcpy is basically an "always-safe" copy function that doesn't have the defects of strcpy_s (does nothing if the dest is too small, instead of copying as much as it safely can) or strncpy (doesn't always null-terminate the result; and always touches every byte of the dest area, which can be a massive time-waster for large dest buffers). The only problem with strlcpy is that it's not supported on many platforms, any more than strcpy_s is... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Reentrant Programs and Protected Storage
> In a nonAPF environment, I don't know if marking a program RENT > does anything at all. Well, it means that if multiple subtasks LINK to it simultaneously, only one copy gets loaded. :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Reentrant Programs and Protected Storage
> It has ALWAYS been this way. When you link a program "RENT" you're telling > the system that the program does not modify itself. Really? I thought that was what REFR was for, not RENT. My understanding was that RENT simply means that the module can be executed my multiple tasks simultaneously. I have written modules that were reentrant, but which modified themselves. (I'm not saying it was a good idea.) They were very careful with their modifications (using CS / CDS, etc), but the fact remains, they were reentrant. But not refreshable. Regards, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: A modest PARM proposal
> Likewise, if the "clever person" calls the program from JCL > with the (proposed) 10,000-character PARM and the program crashes, > it is the caller who is at fault, neither the program nor the > JCL converter. But I have trouble with "intended". A careful > programmer should allow for the possibility that the "clever" > user may attempt to call the program beyond the intent. This > should be enforced not only by documentation "I told you not > to do that?", but by the program's checking and exiting with > a meaningful error message when the presumed limits are > violated. Perhaps, but you can take it too far. I once saw a program where, following every GETMAIN R, the programmer was carefully checking the return code and issuing messages if it was non-zero -- despite the fact that GETMAIN R is documented to always return 0 (unless CHECKZERO=YES is specified, which was not the case). You can spend a lot of time checking things that don't need to be checked. Yes, a program could start with a check that the PARM length is 100 or less. But it's redundant, needless effort when the target calling environment guarantees this already. The hypothetical "clever Person" should expect that, when calling a program outside its target environment, all bets are off. That said, I'm certainly in favour of an expanded PARM in some form. But not one that I know is going to break a lot of existing code (including some that I've personally seen). Cheers, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: A modest PARM proposal
> The PARM is not documented as being limited to 100 bytes. Rexx > Language can pass PARMS of up to 32767 bytes; Assembly Language > up to 65535. 100 is merely a restriction built into Job Control > Language, and documented in the JCL manual. In other words, PARM *is* documented as being limited to 100 bytes. At least where JCL is concerned. Nobody has ever tried to claim that programs called in other ways are limited to 100 bytes of parameters. But there is plenty of documentation about JCL PARMs. 100 bytes. The Language Environment manuals even provide sample COBOL code to receive a JCL PARM, and hard-code the 100-character limit. If a program is only intended to be called from JCL, and it does not cope with being called with longer parameters, then the program is not broken. It is following the rules, and functioning as intended. If some clever person calls the program from REXX with a 10,000-character PARM and the program crashes, it is the caller who is at fault. They were not calling the program as intended. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM book prices
For most manuals, softcopy is fine. But having a hardcopy Reference Summary is *useful*. It's the number one manual I refer to, by a long shot, and in the time it would take me to open a softcopy version and lookup what I want, I can be long since finished with the hardcopy version. Printing out the softcopy version is not the same, by the way. Not even close. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Long parms ... again (was: Reading DD card information)
> Sorry if I wasn't clear. I meant that an LE option could be used to > control whether a user batch program would see > 100 character parms. > I'm suggesting that z/OS itself be extended to support > 100 character PARMS > (somehow), but that an LE option would control whether a user program would > ever see > 100 characters. Seems to me that it would be cleaner, and probably make more sense, if JCL supported a PARMX parameter which was *not* passed to programs in the normal way. Instead, provide a way for programs to *ask* for the PARMX: a macro for Assembler programs, and an LE call for HLLs. This would not break any compatibility at all. Regards, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Long parms ... again (was: Reading DD card information)
> You know the rest. It says "example" and "convention", not > "standard". Regardless, I'd like to see the two-byte length > followed by the PARM field preserved in any extension of a > PARM-like operand to a 65536 (it says "two-byte", not "halfword", > avoiding the implication that it's signed), or even just 32767 > byte length. It's what would be most compatible with programs > that already usefully accept PARMs of several hundred characters > when called by other programs or Rexx ATTACHMVS. > > And a cautionary note which would be wisely heeded: > >To prevent possible errors, always use the count as a length >attribute in acquiring the information in the PARM field. > > I believe that any program which malfunctions because it ignores > this admonition can rightly be considered defective. You ignore all the very explicit statements that IBM makes in other places. The JCL Reference Manual explicitly states that the maximum PARM length is 100 characters. The Language Environment Programming Guide explicitly tells COBOL or PL/1 applications programmers to rely on a maximum length of 100 (see the section on "Preparing Your Main routine to Receive Parameters"). Any programmers who abide by these statements are not producing defective code. They are following IBM's rules. Increasing the PARM length will break perfectly valid current code. Regards, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Reading DD card information
> Oh, drudge away! (Or, even "dredge" if you prefer.)
>
> I wouldn't mind changing my JCL to enable this. A couple
> possibilities:
>
> o Support for symbol substitution in SYSIN data sets, so
> one might code:
>
> //STDPARM DD *,SYMBOLS=YES
> FOO=&FOO
> BAR=&BAR
> ...
>
> (wouldn't you like to be able to substitute JCL symbols
> in STDIN for COZBATCH?)
>
> o Or support in JCL to pass these in the second, third, ...
> arguments as in CALL (and without the 100-character limit):
>
> //STEP EXEC PGM=MYPROG,PARM=(LIST,XREF),
> // ALTPARM=('alternate DDNAME list','FOO=&FOO','BAR=&BAR',...)
>
> -- gil
Or how about just:
// IF ('&FOO' EQ 'FOO') THEN
// ...
// ENDIF
This facility would help us a *lot*.
Allen
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Started Task Abends S522
> Hi, All, > > This is a new one on me: A started task abends S522 after our JWT > interval. This task is basically a TCPIP Sockets listener (part of an > IBM product), and will be "inactive" frequently for long(er than our > JWT) periods of time. > > I don't recall ever having seen a started task go s522 before. Any > ideas? (It's probably something obvious, but I can't see it.) > > TIA, > > -jc- I had a similar problem with a TCPIP Sockets listener. I "fixed" it by setting a timer with STIMERM, and then waiting on the timer ECB as well as the TCPIP ECB. When the timer pops, I simply reset it. Thus, my task wakes up every few minutes for a microsecond or so, whether it's received any connections or not. Problem solved. :) Cheers, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking
> Does anyone here recall any published news articles or incidents > involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you > personally know of any incidents? > > Or have any such been kept on the QT? Anyone who's read "The Adolescence of P-1" by Thomas Ryan will know exactly how to do it. :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Article Mainframe Stolen
> The Y2K office which coordinated all of the efforts for an oil company > I worked at got a report that its 2 fairly new supertankers had Y2K > vunerabilities (obviously they got fixed prior to Y2K). My small > town's volunteer fire department got a fix for one of their fire > engines for a maintenance computer chip that would not allow the > engine to start if past maintenance interval. Since a fair number of > members were also mechanics at the local car dealership and related > gas station and body repair shop, they knew how to bypass to bypass > the problem but it wasn't the sort of thing you would want to deal > with on the way to the fire. I don't believe that I heard about any > known problems with cars. In one of the local offices where I work, staff were at their computers, monitoring their systems, on the night of Y2K. And right at the stroke Of midnight, some clever fellow turned off the lights. There was subdued panic until he turned them back on again. :) Regards, Allen Gainsford -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: AMODE Switching
>>* LOAD the table; R1 has address, R0 has size in doublewords >>* Get storage below the line using the R0 value * 8 >>* Copy the table to your gotten storage > > Instead of copying it, use IARVSERV to map it below the line. > > -- > Tom Marchant Surely, if the table has internal pointers (adcons), these will still point above the line and thus be unusable in AMODE 24? Regards, Allen Gainsford -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
