INFO-VAX Thu, 15 Nov 2007 Volume 2007 : Issue 626
Contents:
Getting Fortran to read CTRL/Z in a file as data
Re: Getting Fortran to read CTRL/Z in a file as data
Re: Getting Fortran to read CTRL/Z in a file as data
Re: Getting Fortran to read CTRL/Z in a file as data
Re: LANCP SHO DEV /CHAR doesn't
Re: Mylex 960 question
Status of the VMS Hobbyist media kit(s) ?
Re: Status of the VMS Hobbyist media kit(s) ?
Re: system constants in COBOL
Re: system constants in COBOL
Re: system constants in COBOL
Re: system constants in COBOL
Re: system constants in COBOL
Re: system constants in COBOL
Re: system constants in COBOL
Re: system constants in COBOL
Re: system constants in COBOL
Re: system constants in COBOL
Re: system constants in COBOL
Re: system constants in COBOL
Re: system constants in COBOL
Re: TCPIP SMTP and/or BIND Resolver bug
Re: VIOC: sizing and performance
Re: VIOC: sizing and performance
Re: VIOC: sizing and performance
----------------------------------------------------------------------
Date: Thu, 15 Nov 2007 13:50:50 +0000
From: Tom Wade <nospam@picard.eurokom.ie>
Subject: Getting Fortran to read CTRL/Z in a file as data
Message-ID: <I4Y_i.23209$j7.435123@news.indigo.ie>
Greetings,
I noticed that a Fortran program I wrote is interpreting a CTRL/Z buried
in a file as an end-of-file condition (I knew it took terminal CTRL/Z as
EOF, but I had never realized it did the same for files). Before I
rewrite the Fortran READs as calls to $GET, is there an easier way to
tell Fortran not to regard CTRL/Z as end-of-file ?
Thanks
---------------------------------------------------------
Tom Wade | EMail: tee dot wade at eurokom dot ie
EuroKom | Tel: +353 (1) 296-9696
A2, Nutgrove Office Park | Fax: +353 (1) 296-9697
Rathfarnham | Disclaimer: This is not a disclaimer
Dublin 14 | Tip: "Friends don't let friends do Unix !"
Ireland
------------------------------
Date: Thu, 15 Nov 2007 06:03:55 -0800 (PST)
From: Bob Gezelter <gezelter@rlgsc.com>
Subject: Re: Getting Fortran to read CTRL/Z in a file as data
Message-ID: <92654c6d-2a09-4823-86f9-80bd19182013@d50g2000hsf.googlegroups.com>
On Nov 15, 8:50 am, Tom Wade <nos...@picard.eurokom.ie> wrote:
> Greetings,
>
> I noticed that a Fortran program I wrote is interpreting a CTRL/Z buried
> in a file as an end-of-file condition (I knew it took terminal CTRL/Z as
> EOF, but I had never realized it did the same for files). Before I
> rewrite the Fortran READs as calls to $GET, is there an easier way to
> tell Fortran not to regard CTRL/Z as end-of-file ?
>
> Thanks
>
> ---------------------------------------------------------
> Tom Wade | EMail: tee dot wade at eurokom dot ie
> EuroKom | Tel: +353 (1) 296-9696
> A2, Nutgrove Office Park | Fax: +353 (1) 296-9697
> Rathfarnham | Disclaimer: This is not a disclaimer
> Dublin 14 | Tip: "Friends don't let friends do Unix !"
> Ireland
Tom,
What is OPEN statement for this file? In particular, what options are
you using to read this file?
- Bob Gezelter, http://www.rlgsc.com
------------------------------
Date: Thu, 15 Nov 2007 07:13:34 -0800 (PST)
From: Fekko Stubbe <fekko.stubbe@kadaster.nl>
Subject: Re: Getting Fortran to read CTRL/Z in a file as data
Message-ID: <dd6586a1-ab38-42bf-a9b4-2e66d38a2fae@b32g2000hsa.googlegroups.com>
Hi Tom
After the fortran read has seen the EOF, try to read the next line. If
that also is EOF, you found the real EOF (or the second ^Z in
succession).
If the next read gets normal data you can go on reading the file
Example program below
character*80 line
open(1,file='x.x',status='old')
c
10 read(1,2000,end=20) nk,line
2000 format(q,a)
15 write(*,*) line(1:nk)
goto 10
c
c We saw an EOF, if the next is again an EOF, all is done
c
20 write(*,*) 'Seen eof'
read(1,2000,end=90) nk,line
c
c If not EOF again, keep on going
c
goto 15
90 end
------------------------------
Date: 15 Nov 2007 09:42:36 -0600
From: briggs@encompasserve.org
Subject: Re: Getting Fortran to read CTRL/Z in a file as data
Message-ID: <vEka7HRFZfM2@eisner.encompasserve.org>
In article <92654c6d-2a09-4823-86f9-80bd19182013@d50g2000hsf.googlegroups.com>, Bob Gezelter <gezelter@rlgsc.com> writes:
> What is OPEN statement for this file? In particular, what options are
> you using to read this file?
It's easy enough to reproduce. A control-z on a line by itself in
an RMS file is treated as EOF for the purpose of Fortran formatted I/O.
options /extend_source
implicit none
integer recl
character *512 record
open ( unit=1, file='test.txt', status='old' )
do while ( .true. )
read ( 1, '(q,a)' ) recl, record
type *, recl, record(1:recl)
end do
end
$ type test.txt
abc
fdsa
<^Z> (Fudged -- cut and paste didn't do justice to the reverse ?)
asdf
$ r test
3 abc
4 fdsa
%FOR-F-ENDDURREA, end-of-file during read
unit 1 file EISNER$DRA3:[DECUSERVE_USER.BRIGGS]TEST.TXT;20
[... snip traceback ...]
$
This behavior comes as a shock to me. On VMS a control-Z is just a
byte in a file. The following makes it pretty clear that the current
behavior is incorrect.
from http://www.cs-software.com/software/fortran/compaq/relnotes.htm
"The run-time support was improperly positioning before the last character in a
file opened with form='binary' and position='append' if the character happened
to be a control-z character, an achar(26). The run-time support was fixed to
not skip the control-z under these conditions. (cvf11664)
If you're going to append _after_ a control-Z then you obviously can't
treat control-Z as end-of-file.
------------------------------
Date: Thu, 15 Nov 2007 11:01:59 -0000
From: "Richard Brodie" <R.Brodie@rl.ac.uk>
Subject: Re: LANCP SHO DEV /CHAR doesn't
Message-ID: <fhh8v9$sn3$1@south.jnrs.ja.net>
"Wilm Boerhout" <w6OLD.PAINTboerhout@planet.nl> wrote in message
news:473a1070$0$25496$ba620dc5@text.nova.planet.nl...
> A VAX is s'posed to know about Full/Half Duplex right?
I don't think so, no. FD capable interfaces started appearing roughly at the same
time as the first Alphas. I think all the FD capable interfaces were PCI* based.
------------------------------
Date: Thu, 15 Nov 2007 08:01:18 -0800 (PST)
From: H Vlems <hvlems@freenet.de>
Subject: Re: Mylex 960 question
Message-ID: <7eb699e8-d337-4210-967c-5dfc45fbcaf5@y5g2000hsf.googlegroups.com>
On 14 nov, 03:51, "Martin Vorlaender" <m...@pdv-systeme.de> wrote:
> H Vlems wrote:
> > Malcolm Dunnett wrote:
> >> H Vlems wrote:
> >> > Of course it turned out to be a little more complicated because the
> >> > ARC software wouldn't load the
> >> > RA200RCU.EXE utility. The first suspect was the floppy itself, though
> >> > it could be read on a PC.
> >> > A copy failed and also a third one with a fresh copy of RA200RCU.EXE
> >> > from another source.
> >> > Hardware failure? No, it appeared that the flat cable was no longer
> >> > connected to the floppy drive.
>
> >> IIRC you can also find a copy of RA200RCU on the Alpha firmware update
> >> CDs, under a Storageworks directory.
>
> > OK, but is it accessible from the ARC console? I've only used it to
> > run utiliies from the floppy drive.
> > The screen itself just lists onde device A: so it feels as if there's
> > no choice but to use a floppy.
> > What's the cdrom drive called then, D:?
>
> IIRC, there's a drop-down list in the "Execute program" item for the
> drive with entries for "A:" and "CDROM:".
>
> The contents of the "Path" text field should be something like
> "\utilities\swxcr\ra200rcu.exe".
>
> Disclaimer: all of this is from memory.
>
> cu,
> Martin
> --
> One OS to rule them all | Martin Vorlaender | OpenVMS rules!
> One OS to find them | work: m...@pdv-systeme.de
> One OS to bring them all | http://vms.pdv-systeme.de/users/martinv/
> And in the Darkness bind them.| home: martin.vorlaen...@t-online.de
Martin, thanks for the hint. I will check that and post the results.
------------------------------
Date: Thu, 15 Nov 2007 14:25:35 GMT
From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?=
Subject: Status of the VMS Hobbyist media kit(s) ?
Message-ID: <zFY_i.392$R_4.214@newsb.telia.net>
Hi.
Just a quickie...
Anyone know the current status of the VMS
Hobbyist media CD ? Is it orderable ?
HP is asking aprox $1000 USD localy over here
in Sweden for a LP-kit...
Jan-Erik.
------------------------------
Date: Thu, 15 Nov 2007 15:01:58 GMT
From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?=
Subject: Re: Status of the VMS Hobbyist media kit(s) ?
Message-ID: <GbZ_i.393$R_4.169@newsb.telia.net>
Jan-Erik Söderholm wrote:
> Hi.
> Just a quickie...
>
> Anyone know the current status of the VMS
> Hobbyist media CD ? Is it orderable ?
>
> HP is asking aprox $1000 USD localy over here
> in Sweden for a LP-kit...
>
> Jan-Erik.
Got a personal mail from Steven M. Schweda, but his/your
mail system rejected my reply.
- SMTP protocol diagnostic: 550 Your IP address or
subnet is in my list of bad ones.
I'm using the largets ISP in Sweden, and I do not
have any mail problems otherwise.
Jan-Erik.
------------------------------
Date: Thu, 15 Nov 2007 11:34:10 GMT
From: VAXman- @SendSpamHere.ORG
Subject: Re: system constants in COBOL
Message-ID: <S8W_i.5$BV5.4@newsfe08.lga>
In article <8a757094-7ea1-4d1c-ac0d-daeffb86e4b1@d50g2000hsf.googlegroups.com>, Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> writes:
>
>
>On Nov 14, 4:46 pm, VAXman- @SendSpamHere.ORG wrote:
>> I've been working with a customer on some COBOL
>:
>> how to implement the constants for system services
>:
>> and then create and compile a small macro with:
>>
>> $LNMDEF GLOBAL
>> .END
>>
>> and link with the program.
>
>Yeah,that's what folks do,
>If it was me, I'd create a DCL / Perl / Macro-defintion tool to turn
>the MACRO $xxxdef sources from STARLET,MLB into cobol include (.LIB)
>files and define the constants in the source instead of having the
>linker resolve them.
I looked at SDL's /LANGUAGES and COBOL is not one of the laugages supported.
I assumed from this that these constants were either not defined, or they're
defined using something very COBOL specific and manually populated.
I'm sure, for now, that having the linker resolve the few symbols being used
will suffice.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
http://tmesis.com/drat.html
------------------------------
Date: Thu, 15 Nov 2007 05:16:48 -0800
From: "Tom Linden" <tom@kednos.company>
Subject: Re: system constants in COBOL
Message-ID: <op.t1t4iat8hv4qyg@murphus.hsd1.ca.comcast.net>
On Wed, 14 Nov 2007 21:01:23 -0800, Hein RMS van den Heuvel
<heinvandenheuvel@gmail.com> wrote:
> On Nov 14, 4:46 pm, VAXman- @SendSpamHere.ORG wrote:
>> I've been working with a customer on some COBOL
> :
>> how to implement the constants for system services
> :
>> and then create and compile a small macro with:
>>
>> $LNMDEF GLOBAL
>> .END
>>
>> and link with the program.
>
> Yeah,that's what folks do,
> If it was me, I'd create a DCL / Perl / Macro-defintion tool to turn
> the MACRO $xxxdef sources from STARLET,MLB into cobol include (.LIB)
> files and define the constants in the source instead of having the
> linker resolve them.
It might be easier to start with PLI$STARLET lib as its data types are
a superset of Cobol's. I guess Digital never thought anyone would use
Cobol for systems programming, otherwise they might have written a
Cobol backend for SDL. Actually, thinking about it, taking the PL/I
backend and modifying it for Cobol might be easier.
>
> fwiw,
> Hein
--
PL/I for OpenVMS
www.kednos.com
------------------------------
Date: Thu, 15 Nov 2007 13:32:50 GMT
From: VAXman- @SendSpamHere.ORG
Subject: Re: system constants in COBOL
Message-ID: <6UX_i.49$BV5.5@newsfe08.lga>
In article <op.t1t4iat8hv4qyg@murphus.hsd1.ca.comcast.net>, "Tom Linden" <tom@kednos.company> writes:
>
>
>On Wed, 14 Nov 2007 21:01:23 -0800, Hein RMS van den Heuvel
><heinvandenheuvel@gmail.com> wrote:
>
>> On Nov 14, 4:46 pm, VAXman- @SendSpamHere.ORG wrote:
>>> I've been working with a customer on some COBOL
>> :
>>> how to implement the constants for system services
>> :
>>> and then create and compile a small macro with:
>>>
>>> $LNMDEF GLOBAL
>>> .END
>>>
>>> and link with the program.
>>
>> Yeah,that's what folks do,
>> If it was me, I'd create a DCL / Perl / Macro-defintion tool to turn
>> the MACRO $xxxdef sources from STARLET,MLB into cobol include (.LIB)
>> files and define the constants in the source instead of having the
>> linker resolve them.
>
>It might be easier to start with PLI$STARLET lib as its data types are
>a superset of Cobol's. I guess Digital never thought anyone would use
>Cobol for systems programming, otherwise they might have written a
>Cobol backend for SDL. Actually, thinking about it, taking the PL/I
>backend and modifying it for Cobol might be easier.
You've piqued my curiosity. Was there a documented way to extend SDL
for other lingos?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
http://tmesis.com/drat.html
------------------------------
Date: Thu, 15 Nov 2007 13:44:25 GMT
From: "Tim E. Sneddon" <tesneddon@bigpond.com>
Subject: Re: system constants in COBOL
Message-ID: <473C4D39.3060502@bigpond.com>
VAXman- @SendSpamHere.ORG wrote:
> In article <op.t1t4iat8hv4qyg@murphus.hsd1.ca.comcast.net>, "Tom Linden" <tom@kednos.company> writes:
>>
>> On Wed, 14 Nov 2007 21:01:23 -0800, Hein RMS van den Heuvel
>> <heinvandenheuvel@gmail.com> wrote:
>>
>>> On Nov 14, 4:46 pm, VAXman- @SendSpamHere.ORG wrote:
>>>> I've been working with a customer on some COBOL
>>> :
>>>> how to implement the constants for system services
>>> :
>>>> and then create and compile a small macro with:
>>>>
>>>> $LNMDEF GLOBAL
>>>> .END
>>>>
>>>> and link with the program.
>>> Yeah,that's what folks do,
>>> If it was me, I'd create a DCL / Perl / Macro-defintion tool to turn
>>> the MACRO $xxxdef sources from STARLET,MLB into cobol include (.LIB)
>>> files and define the constants in the source instead of having the
>>> linker resolve them.
>> It might be easier to start with PLI$STARLET lib as its data types are
>> a superset of Cobol's. I guess Digital never thought anyone would use
>> Cobol for systems programming, otherwise they might have written a
>> Cobol backend for SDL. Actually, thinking about it, taking the PL/I
>> backend and modifying it for Cobol might be easier.
>
> You've piqued my curiosity. Was there a documented way to extend SDL
> for other lingos?
>
Yes there is, I have written two (with a third half done). They generate
definitions for XML Schema Definition (XSD), Java for use with the J2VMS
package and Perl. The source (as well as documentation and executables)
for the PL/I version is available on the Freeware CDs. However, although
it has been discussed I don't believe there will be a source release of
the latest C++ version any time soon.
Regards, Tim.
------------------------------
Date: 15 Nov 2007 07:56:52 -0600
From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)
Subject: Re: system constants in COBOL
Message-ID: <hf2MyFPK1MrU@eisner.encompasserve.org>
In article <8a757094-7ea1-4d1c-ac0d-daeffb86e4b1@d50g2000hsf.googlegroups.com>, Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> writes:
>
> Yeah,that's what folks do,
> If it was me, I'd create a DCL / Perl / Macro-defintion tool to turn
> the MACRO $xxxdef sources from STARLET,MLB into cobol include (.LIB)
> files and define the constants in the source instead of having the
> linker resolve them.
I wouldn't since that's not a documented, supported interface and
I've seen it break in the past.
------------------------------
Date: Thu, 15 Nov 2007 14:11:42 GMT
From: VAXman- @SendSpamHere.ORG
Subject: Re: system constants in COBOL
Message-ID: <ysY_i.62$wR2.57@newsfe09.lga>
In article <473C4D39.3060502@bigpond.com>, "Tim E. Sneddon" <tesneddon@bigpond.com> writes:
>
>
>VAXman- @SendSpamHere.ORG wrote:
>> In article <op.t1t4iat8hv4qyg@murphus.hsd1.ca.comcast.net>, "Tom Linden" <tom@kednos.company> writes:
>>>
>>> On Wed, 14 Nov 2007 21:01:23 -0800, Hein RMS van den Heuvel
>>> <heinvandenheuvel@gmail.com> wrote:
>>>
>>>> On Nov 14, 4:46 pm, VAXman- @SendSpamHere.ORG wrote:
>>>>> I've been working with a customer on some COBOL
>>>> :
>>>>> how to implement the constants for system services
>>>> :
>>>>> and then create and compile a small macro with:
>>>>>
>>>>> $LNMDEF GLOBAL
>>>>> .END
>>>>>
>>>>> and link with the program.
>>>> Yeah,that's what folks do,
>>>> If it was me, I'd create a DCL / Perl / Macro-defintion tool to turn
>>>> the MACRO $xxxdef sources from STARLET,MLB into cobol include (.LIB)
>>>> files and define the constants in the source instead of having the
>>>> linker resolve them.
>>> It might be easier to start with PLI$STARLET lib as its data types are
>>> a superset of Cobol's. I guess Digital never thought anyone would use
>>> Cobol for systems programming, otherwise they might have written a
>>> Cobol backend for SDL. Actually, thinking about it, taking the PL/I
>>> backend and modifying it for Cobol might be easier.
>>
>> You've piqued my curiosity. Was there a documented way to extend SDL
>> for other lingos?
>>
>
>Yes there is, I have written two (with a third half done). They generate
>definitions for XML Schema Definition (XSD), Java for use with the J2VMS
>package and Perl. The source (as well as documentation and executables)
>for the PL/I version is available on the Freeware CDs. However, although
>it has been discussed I don't believe there will be a source release of
>the latest C++ version any time soon.
OK. When I get some time, I'll look into it.
The COBOL thing was a quickie 2 hour project. It is certainly something
that I wouldn't wish to do on a daily basis. COBOL is *WAY TOO* verbose!
My fingers just don't work like they used to and all that typing would be
mch effort for them.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
http://tmesis.com/drat.html
------------------------------
Date: 15 Nov 2007 08:30:02 -0600
From: Kilgallen@SpamCop.net (Larry Kilgallen)
Subject: Re: system constants in COBOL
Message-ID: <eUofuSsj+XaU@eisner.encompasserve.org>
In article <ysY_i.62$wR2.57@newsfe09.lga>, VAXman- @SendSpamHere.ORG writes:
> In article <473C4D39.3060502@bigpond.com>, "Tim E. Sneddon" <tesneddon@bigpond.com> writes:
>>
>>
>>VAXman- @SendSpamHere.ORG wrote:
>>> You've piqued my curiosity. Was there a documented way to extend SDL
>>> for other lingos?
>>>
>>
>>Yes there is, I have written two (with a third half done). They generate
>>definitions for XML Schema Definition (XSD), Java for use with the J2VMS
>>package and Perl. The source (as well as documentation and executables)
>>for the PL/I version is available on the Freeware CDs. However, although
>>it has been discussed I don't believe there will be a source release of
>>the latest C++ version any time soon.
>
> OK. When I get some time, I'll look into it.
As I recall saying the mechanism is "documented" is exaggeration.
As Tim says, the sources are Freeware and you can build your own.
Each language to be output uses a separate shareable image, which
is the part you will be writing.
------------------------------
Date: Thu, 15 Nov 2007 14:38:16 GMT
From: "Tim E. Sneddon" <tesneddon@bigpond.com>
Subject: Re: system constants in COBOL
Message-ID: <473C59D8.3050609@bigpond.com>
Larry Kilgallen wrote:
> In article <ysY_i.62$wR2.57@newsfe09.lga>, VAXman- @SendSpamHere.ORG writes:
>> In article <473C4D39.3060502@bigpond.com>, "Tim E. Sneddon" <tesneddon@bigpond.com> writes:
>>>
>>> VAXman- @SendSpamHere.ORG wrote:
>
>>>> You've piqued my curiosity. Was there a documented way to extend SDL
>>>> for other lingos?
>>>>
>>> Yes there is, I have written two (with a third half done). They generate
>>> definitions for XML Schema Definition (XSD), Java for use with the J2VMS
>>> package and Perl. The source (as well as documentation and executables)
>>> for the PL/I version is available on the Freeware CDs. However, although
>>> it has been discussed I don't believe there will be a source release of
>>> the latest C++ version any time soon.
>> OK. When I get some time, I'll look into it.
>
> As I recall saying the mechanism is "documented" is exaggeration.
> As Tim says, the sources are Freeware and you can build your own.
> Each language to be output uses a separate shareable image, which
> is the part you will be writing.
I foundthe documentation to be quite decent. It may be a little out of date.
However, I wouldn't call it an exaggeration. The back of the VAX SDL manual
has it all.
Regards, Tim.
------------------------------
Date: Thu, 15 Nov 2007 15:10:33 GMT
From: VAXman- @SendSpamHere.ORG
Subject: Re: system constants in COBOL
Message-ID: <JjZ_i.82$wR2.5@newsfe09.lga>
In article <eUofuSsj+XaU@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>
>
>In article <ysY_i.62$wR2.57@newsfe09.lga>, VAXman- @SendSpamHere.ORG writes:
>> In article <473C4D39.3060502@bigpond.com>, "Tim E. Sneddon" <tesneddon@bigpond.com> writes:
>>>
>>>
>>>VAXman- @SendSpamHere.ORG wrote:
>
>>>> You've piqued my curiosity. Was there a documented way to extend SDL
>>>> for other lingos?
>>>>
>>>
>>>Yes there is, I have written two (with a third half done). They generate
>>>definitions for XML Schema Definition (XSD), Java for use with the J2VMS
>>>package and Perl. The source (as well as documentation and executables)
>>>for the PL/I version is available on the Freeware CDs. However, although
>>>it has been discussed I don't believe there will be a source release of
>>>the latest C++ version any time soon.
>>
>> OK. When I get some time, I'll look into it.
>
>As I recall saying the mechanism is "documented" is exaggeration.
>As Tim says, the sources are Freeware and you can build your own.
>Each language to be output uses a separate shareable image, which
>is the part you will be writing.
Yes Larry, I knew the languages were supported via shareable images of the
form SDL${language}.EXE. The help on SDL/LANGUAGES did not list COBOL but
I thought it might be an oversight in the help file so I search SYS$SHARE:.
No SDL$COBOL.EXE.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
http://tmesis.com/drat.html
------------------------------
Date: Thu, 15 Nov 2007 18:28:01 +0100
From: Marc Van Dyck <marc.vandyck@brutele.be>
Subject: Re: system constants in COBOL
Message-ID: <mn.7c547d7bd936045b.30579@brutele.be>
VAXman- @SendSpamHere.ORG was thinking very hard :
> In article <eUofuSsj+XaU@eisner.encompasserve.org>, Kilgallen@SpamCop.net
> (Larry Kilgallen) writes:
>>
>>
>> In article <ysY_i.62$wR2.57@newsfe09.lga>, VAXman- @SendSpamHere.ORG
>> writes:
>>> In article <473C4D39.3060502@bigpond.com>, "Tim E. Sneddon"
>>> <tesneddon@bigpond.com> writes:
>>>>
>>>>
>>>> VAXman- @SendSpamHere.ORG wrote:
>>
>>>>> You've piqued my curiosity. Was there a documented way to extend SDL
>>>>> for other lingos?
>>>>>
>>>>
>>>> Yes there is, I have written two (with a third half done). They generate
>>>> definitions for XML Schema Definition (XSD), Java for use with the J2VMS
>>>> package and Perl. The source (as well as documentation and executables)
>>>> for the PL/I version is available on the Freeware CDs. However, although
>>>> it has been discussed I don't believe there will be a source release of
>>>> the latest C++ version any time soon.
>>>
>>> OK. When I get some time, I'll look into it.
>>
>> As I recall saying the mechanism is "documented" is exaggeration.
>> As Tim says, the sources are Freeware and you can build your own.
>> Each language to be output uses a separate shareable image, which
>> is the part you will be writing.
>
>
> Yes Larry, I knew the languages were supported via shareable images of the
> form SDL${language}.EXE. The help on SDL/LANGUAGES did not list COBOL but
> I thought it might be an oversight in the help file so I search SYS$SHARE:.
> No SDL$COBOL.EXE.
Well, as far as I know, SDL has been developped by the engineers who
developped VAX/VMS itself, because they needed it for their own work.
And as there isn't any part of VAX/VMS that was coded in Cobol, there
is no SDL backend for Cobol either. It's that simple...
--
Marc Van Dyck
------------------------------
Date: Thu, 15 Nov 2007 09:52:47 -0800 (PST)
From: "David P. Murphy" <dpm_google@myths.com>
Subject: Re: system constants in COBOL
Message-ID: <c6b2f73b-e6ee-433b-8945-76f54080c152@b36g2000hsa.googlegroups.com>
On Nov 15, 9:11 am, VAXman- @SendSpamHere.ORG wrote:
> The COBOL thing was a quickie 2 hour project. It is certainly something
> that I wouldn't wish to do on a daily basis. COBOL is *WAY TOO* verbose!
> My fingers just don't work like they used to and all that typing would be
> mch effort for them.
My first guess is that you would write the entire thing in MACRO-32
and
have a single line of COBOL, which would be a PERFORM to invoke your
*real* code.
But I suppose there's a good reason you can't do it that way ;-)
ok
dpm
------------------------------
Date: Thu, 15 Nov 2007 18:12:31 GMT
From: VAXman- @SendSpamHere.ORG
Subject: Re: system constants in COBOL
Message-ID: <j_%_i.213$wR2.12@newsfe09.lga>
In article <c6b2f73b-e6ee-433b-8945-76f54080c152@b36g2000hsa.googlegroups.com>, "David P. Murphy" <dpm_google@myths.com> writes:
>
>
>On Nov 15, 9:11 am, VAXman- @SendSpamHere.ORG wrote:
>
>> The COBOL thing was a quickie 2 hour project. It is certainly something
>> that I wouldn't wish to do on a daily basis. COBOL is *WAY TOO* verbose!
>> My fingers just don't work like they used to and all that typing would be
>> mch effort for them.
>
>My first guess is that you would write the entire thing in MACRO-32
>and
>have a single line of COBOL, which would be a PERFORM to invoke your
>*real* code.
>
>But I suppose there's a good reason you can't do it that way ;-)
I have written thousands of lines of code for this group over the years.
Mostly all in Macro and setup like a library for them to call from COBOL.
For some reason , however, the were trying to write some code that would
call a few system services and needed some help. This is where I came in
to the project. Probably because what they wanted to do couldn't be done
with a DCL procedure and LIB$SPAWN from COBAL (which they know how to do
very well).
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
http://tmesis.com/drat.html
------------------------------
Date: 15 Nov 2007 12:45:28 -0600
From: Kilgallen@SpamCop.net (Larry Kilgallen)
Subject: Re: system constants in COBOL
Message-ID: <wXZbAWf6F127@eisner.encompasserve.org>
In article <mn.7c547d7bd936045b.30579@brutele.be>, Marc Van Dyck <marc.vandyck@brutele.be> writes:
> Well, as far as I know, SDL has been developped by the engineers who
> developped VAX/VMS itself, because they needed it for their own work.
> And as there isn't any part of VAX/VMS that was coded in Cobol, there
> is no SDL backend for Cobol either. It's that simple...
Over the years various groups in DEC wrote various other SDL backends
that are not part of the base SDL non-product. So I think the issue
is whether any of those other SDL backends was for Cobol and if so,
whether that Cobol backend got release on the VMS Freeware or any
other channel accessible to someone who currently has the problem.
------------------------------
Date: Thu, 15 Nov 2007 02:16:08 -0500
From: JF Mezei <jfmezei.spamnot@vaxination.ca>
Subject: Re: TCPIP SMTP and/or BIND Resolver bug
Message-ID: <16393$473bf23c$cef8887a$14712@TEKSAVVY.COM>
FrankS wrote:
>> Subject: Re: White fluffy sheep
>
> You're worried about spam issues, but I'd be more worried about your
> personal reputation.
>
> "White fluffy sheep"? What type of unnatural acts have you been
> discussing?
What may be "unnatural" to you may be perfectly natural to others :-)
Did you know that Australia has more sheep than New Zealand ?
Besides, there isn't much I could say to worsen my reputation here.
(and no, that wasn't the original subject of the message).
---
OK, followed suggestions made by many and downloaded a huge ECO2 just to
view the release notes.
The release notes for :
DEC AXPVMS TCPIP V5.6-9ECO2 Layered Product
Make no mention of changes to how SMTP handles domain name translation
failure due to DNS server being unreacheable (as opposed to a negative
response from a reacheable DNS server). So that ECO won't fix this problem.
Also, I saw no mention of the POP server security problem I had reported
earlier (it allows someone to try 5 billion passwords without generating
intrusion detection or anything in the logs).
------------------------------
Date: Thu, 15 Nov 2007 03:15:06 -0800 (PST)
From: Bob Gezelter <gezelter@rlgsc.com>
Subject: Re: VIOC: sizing and performance
Message-ID: <48ec48e2-cf75-486c-925b-2beac222d123@k62g2000hse.googlegroups.com>
On Nov 14, 11:46 pm, Ken Fairfield <K...@Napili.Fairfield.Home> wrote:
> We have a four-node VMSCluster consisting of two GS1280 "frames",
> each partitioned into two nodes. For reasons best known to the
> vendor of the primary application, Cerner Millennium, we're using
> VIOC rather than XFC file caching. The cluster is not homogeneous
> in that one node is dedicated to "non-production" versions of the
> application, one node is the production database server, and two
> nodes share the production "application server" duties (tier 2 in
> a 3-tier architecture).
>
> That said, the vendor is asking us to set VCC_MAXSIZE <= 256000,
> whereas we have it set to 512000 on two nodes, and 768000 on a
> third.
>
> Looking at SHOW MEMORY/CACHE/FULL on the three production nodes,
> I see Read Hit Rates of 58% (database node, 512000 maxsize),
> 15% on app server node w/512000 maxsize, and 66% on the other app
> server node w/768000 maxsize (the non-prod node is at 256000 and
> has a hit rate of 71%).
>
> Question: What is the best, or at least a good, indicator of
> VIOC effectiveness? Is it the read hit rate, or something else?
> Secondly, what would one expect the effect would be of *reducing*
> VCC_MAXSIZE by 50%, or even 75% in the one case?
>
> I'm concerned that the vendor is making these recommendations
> without taking into consideration the actual potential performance
> impacts. Their comment reads like so:
>
> "Sets size for closed file cache. 256,000 is the start value.
> This should be tuned down later after full load conditions
> are studied."
>
> I.e., this seems like a new-installation setting, not one based on
> actual running history of over 2 years. And note that every change
> takes a downtime for Autogen then reboot <sigh...>.
>
> Thanks for any and all hints, tips, and/or personal stories. ;-)
>
> -Ken
> --
> Ken & Ann Fairfield
> What: Ken dot And dot Ann
> Where: Gmail dot Com
Ken,
Caches of all types are an excellent candidate for the "Your mileage
will vary". Even in precisely the same application context, the hit
rate is, in essence, a direct manifestation of how the applications
interact with the people who use them. Thus, I have always considered
recommendations as a starting point, with the actual numbers to be
increased or decreased as experience with the operating environment.
While the original post did not include details of the disk
configuration, it is likely that there are (at least) three levels of
caching actually present: within the database, the VIOC/XFC, and the
caching within the storage controller. The optimum performance
settings are a balancing act between all three and their effects.
CPU caches have multiple levels because of size limits inherent to
geometry and packaging, thus they typically have small L1 caches,
backed by ever increasing L2 and, in some cases, L3 caches. This
relationship does not apply in the case of mass storage.
My general recommendation over the years, always tempered by the
actual situation, is to adjust the internal database caches to
maximize performance, and then, to the extent possible, exclude the
database activity from consideration for caching. If a properly tuned
database is releasing data back to mass storage it is probably making
an intelligent choice, particularly if the database cache is tuned
correctly.
As to the hit rate, the effect of a reduction in cache size depends
where on the curve one is at the present value. The general curve for
cache performance is a curve approximating exponential decay of
benefits as size increases. The true metric here is not really hit
rate, but eviction rate: How often data must be evicted from the cache
to make room for other data. A hit rate of 50% with an eviction rate
of 0% is far different than a hit rate of 50% with a 100% eviction
rate (the latter gains by adding size, the former does not).
I would be tempted to arrange things so that the cache is not polluted
by the presence of the data back and forth from the database and
Cache. I would also consider the use of RMS tuning on other active
files as an alternative to the sledgehammer of using the cache size.
Cache size (either XFC or VIOC) is a large, somewhat imprecise tool
for achieving performance. While I will not say that one cannot wield
a sledgehammer with precision, it can be challenge.
I hope that the above is helpful.
- Bob Gezelter, http://www.rlgsc.com
------------------------------
Date: Thu, 15 Nov 2007 08:45:56 -0800 (PST)
From: Ken.Fairfield@gmail.com
Subject: Re: VIOC: sizing and performance
Message-ID: <069bd00d-bcdb-457f-bc5e-733234d52da4@i29g2000prf.googlegroups.com>
My apologies for insufficient information in the post Michael is
following-up. It was a hurried
post last thing in the evening from home. I'm forced to use Google
Groups from work, which
is just a huge spam magnet if I use it for posting, but here goes
anyway...
On Nov 14, 9:43 pm, "Forster, Michael" <mfors...@mcw.edu> wrote:
> What are your Cache resident memory section sizings and how much total and free physical memory?
OK, we're running VMS 7.3-2 with ECO's current as of last Spring,
e.g., UPDATE-V0900 and friends installed.
The systems have the 1.3 GHz CPUs. Database node is 12 CPUs and 40GB
memory. The application
server nodes each have 14 CPUs and 32 GB of memory. The database is
Oracle 9.2.0.5 and we've
got something like 23.5 GB of reserved memory for Oracle SGAs.
Show Memory/Full lists these three nodes as having the following about
of VIOC cache reserved, etc.:
--------------------------------------------------------------------------------------------------------
SYSMAN> do pipe sho mem/ful | sear sys$pipe "virtual i/o"/wind=(0,2)
%SYSMAN-I-OUTPUT, command execution on node DBB1
Virtual I/O Cache: Total Free In Use
Cache Memory (MBytes) 250.00 157.10 92.89
Granularity Hint Regions (pages): Total Free In Use
Released
%SYSMAN-I-OUTPUT, command execution on node APP1
Virtual I/O Cache: Total Free In Use
Cache Memory (MBytes) 250.00 24.14 225.85
Granularity Hint Regions (pages): Total Free In Use
Released
%SYSMAN-I-OUTPUT, command execution on node APP2
Virtual I/O Cache: Total Free In Use
Cache Memory (MBytes) 375.00 0.00 375.00
Granularity Hint Regions (pages): Total Free In Use
Released
SYSMAN>
----------------------------------------------------------------------------------------------------------
Sorry, the output looks kind of funky in proportional fonts...
>
> Cache and Oracle systems have their own memory structures and are not benefitted by XFC.
> On AIX nodes we would reduce the file cache sizing as to not take memory away from Cache
> memory structures.
Again, this is VIOC, *not* XFC*. And I'm not particularly concerned
about the database
node. And 250 MB is not a big hit on a 40GB machine. :-)
> What software is on the tier two?
Its Cerner's Millennium. Thought I said that in the previous post...
> Any Cache server page applications?
Sorry, I don't understand the question.
-Ken
--
Ken & Ann Fairfield
What: Ken dot And dot Ann
Where: Gmail dot Com
------------------------------
Date: Thu, 15 Nov 2007 08:57:10 -0800 (PST)
From: Ken.Fairfield@gmail.com
Subject: Re: VIOC: sizing and performance
Message-ID: <e501e0e2-6701-4a8a-b544-347dbb89c720@e23g2000prf.googlegroups.com>
On Nov 15, 3:15 am, Bob Gezelter <gezel...@rlgsc.com> wrote:
[...]
>
> While the original post did not include details of the disk
> configuration, it is likely that there are (at least) three levels of
> caching actually present: within the database, the VIOC/XFC, and the
> caching within the storage controller. The optimum performance
> settings are a balancing act between all three and their effects.
Right, sorry about that. As in my reply to Michael Forster, I'm
actually less concerned about the database node than the two
application server nodes.
The two application server nodes each have 14x1.3Ghz processors
and 32GB of memory. The storage is on an EVA6000 where we're
using, what's the term, "fully mirrored vdisks"? The VIOC caches
are 250MB on the DB node, 250MB on one app server, and
375MB on the other.
And it is VIOC, *not* XFC, caching.
[...]
> As to the hit rate, the effect of a reduction in cache size depends
> where on the curve one is at the present value. The general curve for
> cache performance is a curve approximating exponential decay of
> benefits as size increases. The true metric here is not really hit
> rate, but eviction rate: How often data must be evicted from the cache
> to make room for other data. A hit rate of 50% with an eviction rate
> of 0% is far different than a hit rate of 50% with a 100% eviction
> rate (the latter gains by adding size, the former does not).
I include here the output of Show Memory/Cache/Full from the
three nodes. What I see is that on each node, about 100 files
are cached. There is a lot of I/O bypassing the cache, and on
the two app server nodes, most of the cache is in use (not much
in the "Free" column. What I can't see from this output is the
eviction rate...
------------------------------------------------------------------------------------
SYSMAN> do sho mem/cach/ful
%SYSMAN-I-OUTPUT, command execution on node DBB1
System Memory Resources on 15-NOV-2007 08:46:58.82
Virtual I/O Cache
Total Size (MBytes) 250.00 Read IO Count
1170423898
Free (MBytes) 151.07 Read Hit Count
670193435
In Use (MBytes) 98.92 Read Hit
Rate 57%
Write IO Bypassing Cache ********* Write IO Count
2501817621
Files Retained 99 Read IO Bypassing Cache
390546546
Write Bitmap (WBM) Memory Summary
Local bitmap count: 251 Local bitmap memory usage (MB)
41.69
Master bitmap count: 117 Master bitmap memory usage (MB)
18.86
%SYSMAN-I-OUTPUT, command execution on node APP1
System Memory Resources on 15-NOV-2007 08:46:58.87
Virtual I/O Cache
Total Size (MBytes) 250.00 Read IO Count
2485755609
Free (MBytes) 22.03 Read Hit Count
371641860
In Use (MBytes) 227.96 Read Hit
Rate 14%
Write IO Bypassing Cache 29108623 Write IO Count
738910797
Files Retained 100 Read IO Bypassing
Cache1954885777
Write Bitmap (WBM) Memory Summary
Local bitmap count: 285 Local bitmap memory usage (MB)
47.58
Master bitmap count: 71 Master bitmap memory usage (MB)
12.17
%SYSMAN-I-OUTPUT, command execution on node APP2
System Memory Resources on 15-NOV-2007 08:46:58.96
Virtual I/O Cache
Total Size (MBytes) 375.00 Read IO Count
103022387
Free (MBytes) 0.03 Read Hit Count
68204994
In Use (MBytes) 374.96 Read Hit
Rate 66%
Write IO Bypassing Cache 2681158 Write IO Count
156859274
Files Retained 100 Read IO Bypassing Cache
497166
Write Bitmap (WBM) Memory Summary
Local bitmap count: 285 Local bitmap memory usage (MB)
47.58
Master bitmap count: 71 Master bitmap memory usage (MB)
12.17
SYSMAN>
------------------------------------------------------------------------------
Thanks, Ken
--
Ken & Ann Fairfield
What: Ken dot And dot Ann
Where: Gmail dot Com
------------------------------
End of INFO-VAX 2007.626
************************