Hi,
Can somebody provide me an example of the D SMS,SHUNTED command. There is
always a syntax error in my command using:
d sms,shunted,sphere(ENGG00.CAPONL.DCDOCA.D0.KS2048) or
d sms,shunted,{sphere(ENGG00.CAPONL.DCDOCA.D0.KS2048)}
Nedbank Limited Reg No 1951/09/06. Th
Buckton, T. (Theo) wrote:
>Can somebody provide me an example of the D SMS,SHUNTED command. There is
>always a syntax error in my command using:
>d sms,shunted,sphere(ENGG00.CAPONL.DCDOCA.D0.KS2048) or
>d sms,shunted,{sphere(ENGG00.CAPONL.DCDOCA.D0.KS2048)}
What do you see if you just do D
Hi
I see that Transactional VSAM must be available for this command to display
something:
D SMS,SHUNTED
IGD034I THE COMMAND IS IGNORED, TRANSACTIONAL VSAM IS NOT AVAILABLE
Thank you
Regards
-Original Message-
From: IBM Mainframe D
Am 19.01.2015 um 23:07 schrieb Tony Harminc:
On 18 January 2015 at 04:29, Bernd Oppolzer wrote:
What do you think about this? For the existing PL/1 code base, for example,
it would be a big change if all pointers would be 8 bytes long ... I don't
see this happen in the near future.
In the PL/I
Sorry, there is an error in the second paragraph which could lead to
severe misunderstandings: "code page" should be "code base".
Kind regards
Bernd
Am 20.01.2015 um 10:32 schrieb Bernd Oppolzer:
Am 19.01.2015 um 23:07 schrieb Tony Harminc:
On 18 January 2015 at 04:29, Bernd Oppolzer wrote
>I don't like the book said this: RDEFINE FACILITY IEAABD.DMPAUTH
UACC(READ).
>I will rather lower the UACC.
We all should agree with not liking that. This was corrected in the z/OS
2.1 publications.
In z/OS 1.13 the example incorrectly had this, but the "guideline"
immediately before the exa
>If now with new releases of the
>OpSys, all modules linked as RENT will be read only,
I'm not sure where that thought came from. The operating system rule has
been in place for way longer than I have.
In general, reentrant modules from APF-authorized concatenations are
placed into key 0 storage
>What about usage of 64 bit dataspaces ...without calling Assembler
Data spaces (as defined by DSPSERV) are limited to 31-bit. I don't see
that ever changing.
Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe
When you specify the grow command, the size you specify has to be the total of
current size+amount to grow by. It’s a little counterintuitive. I've done
this too, and wondered why it didn’t work.
So, when you tried this: zfsadm grow ZFS.SYS01.AGG 17120
It should have been zfsadm grow ZFS.SY
Peter Relson wrote:
>>I don't like the book said this: RDEFINE FACILITY IEAABD.DMPAUTH UACC(READ).
>>I will rather lower the UACC.
>We all should agree with not liking that. This was corrected in the z/OS 2.1
>publications.
Thanks. Much appreciated with lots of thanks.
>>Also, revise IEAABD.DM
Ladies and Gentlemen,
A gentle reminder that the next meeting of the GSE (UK) Enterprise Security
Working Group will take place on Thursday 5th February at CA's Office in Ditton
Park, Datchet, Slough.
To register, please go to http://www.racf.gse.org.uk/content/content_events.php
and click on
On Sun, 18 Jan 2015 10:37:01 -0500, Aled Hughes wrote:
>According to the UK's Daily Mail, COBOL programmers are commanding 'big money'
>especially some of the retired ones. I suspect some of the so-called salaries
>are contractor rated. £50,000 (about US $76K) works out at less than £200 a
>da
Thanks for that Govind. As you say, internet searches don't necessarily mean
diddly.
And I appreciate Shane's comment, sysprogs with 30+ years experience are not
faring any better with contractor rates at ridiculous levels. As the lad said:-
"And anybody actually in a job is keeping their
Jumping in a little late here, but AMODE 64 for *code* is not necessarily the
need for most business purposes. AMODE 64 for *data* is the need that I
perceive as primary. I would be well satisfied if 64-bit data storage could be
used transparently even with code running only in 31-bit storage.
On Tue, 20 Jan 2015 11:12:33 -0500, Farley, Peter x23353 wrote:
>Jumping in a little late here, but AMODE 64 for *code* is not necessarily the
>need for most business purposes. AMODE 64 for *data* is the need that I
>perceive as primary. I would be well satisfied if 64-bit data storage could
In <54be20bf.5030...@t-online.de>, on 01/20/2015
at 10:32 AM, Bernd Oppolzer said:
>if you are building linked lists etc, then pointers are part of
>structures etc., and if you have this, if pointer size changes,
>then offsets of other fields inside structures change, too.
Why is that a pro
In
,
on 01/20/2015
at 08:29 AM, Peter Relson said:
>I don't know of any reentrant code in the BCP in assembler or
>(internal) PL/X for which static does not happen to equate to
>constant-after-load.
While some nonreshaable reentrant code ib OS/360 survived into MVS, my
understanding is that
Hi Folks,
PUT 1412 for z/OS 2.1 and 1.13, is a memorable PUT level (RSU or
whatever). At that level, IBM has retrofitted its UCB lookup changes
that were designed for the next release (2.2?) so that they will also
apply to these earlier releases (HBB7790, HBB7780 and JBB778H). The PTF
n
In <54bce8fd026d0017f...@prv-mh.provo.novell.com>, on 01/19/2015
at 09:22 AM, Mark Post said:
>Of course not, but the things you were talking about are not part of
>the hypervisor features of CP, but the OS itself.
Untrue; CP includes code for error handling. and the port of, e.g,
Solaris
It's been a long time ago since I was active on this listserver due to personal
stuff.
I hope u will like the new version which still isn't free of bugs.
Regards Roland
--
For IBM-MAIN subscribe / signoff / archive access inst
>>> On 1/19/2015 at 04:10 PM, "Shmuel Metz (Seymour J.)"
wrote:
> In <54bce8fd026d0017f...@prv-mh.provo.novell.com>, on 01/19/2015
>at 09:22 AM, Mark Post said:
>
>>Of course not, but the things you were talking about are not part of
>>the hypervisor features of CP, but the OS itself.
>
Am 20.01.2015 um 18:22 schrieb Shmuel Metz (Seymour J.):
In <54be20bf.5030...@t-online.de>, on 01/20/2015
at 10:32 AM, Bernd Oppolzer said:
if you are building linked lists etc, then pointers are part of
structures etc., and if you have this, if pointer size changes,
then offsets of other
Welcome back Roland, appreciate your efforts.
Shane ...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Am 20.01.2015 um 18:43 schrieb Paul Gilmartin:
On Tue, 20 Jan 2015 11:12:33 -0500, Farley, Peter x23353 wrote:
Jumping in a little late here, but AMODE 64 for *code* is not necessarily the
need for most business purposes. AMODE 64 for *data* is the need that I
perceive as primary. I would b
On Wed, 21 Jan 2015 01:24:24 +0100, Bernd Oppolzer wrote:
>
>... Same goes
>for the difference of two pointers; you get the numbers of elements between the
>pointers. That's because every pointer is typed in C.
>
>PL/1 today also allows simple pointer arithmetic, and even with a C-like
>syntax (if
Careful, Paul, you tempt the flames of ardency!
On Tue, Jan 20, 2015 at 10:43 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 21 Jan 2015 01:24:24 +0100, Bernd Oppolzer wrote:
> >
> >... Same goes
> >for the difference of two pointers; you get the numbers of
Hi All,
We have a business requirement and planning to take Backup of few warehouse
INFOPAC(view-direct) reports in readable format which is actually in VSAM
dataset.
Could you please guide me.
Thanks,
Bala
--
For IBM-MAIN su
Am 21.01.2015 um 04:43 schrieb Paul Gilmartin:
On Wed, 21 Jan 2015 01:24:24 +0100, Bernd Oppolzer wrote:
PL/1 today also allows simple pointer arithmetic, and even with a C-like
syntax (if you want):
DCL P PTR;
P = ADDR (X);
P += 5;
/* now P contains the ADDR of X plus 5 */
but unlike C, poi
28 matches
Mail list logo
