RE: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Tony Gravagno]

Mark Johnson wrote:
> In 1978 ... I recall him reviewing a FOR...NEXT loop that had the FOR
part in one
> frame and the NEXT part in another and he was spending time trying to
> put compilable code (not comments) in front of the FOR section in the
> hope that the both the FOR and NEXT were in the same frame. This may
> have had the moniker "Frame Faulting". Mainframes called this a Core
> Dump.

I'm not sure how much the following applies to U2 environments anymore but
I'd be interested if someone compared the info below to how U2 works now
and in the past.

The term Frame Faulting refers to the process where the DBMS is scanning
for data and it encounters an end of frame before the end of the data it
needs.  So it looks at the frame forward link, performs a frame read,
attaches the resulting data to the buffer in memory, then it goes back to
scanning.  It's a time consuming process that is best avoided where
possible, and that's why we all fight so hard to keep data out of overflow.

Pursuant to this discussion, if you have a Mod 1 file and need to
constantly frame fault just looking for item IDs, you're putting an
unnecessary burden on the environment.  Doesn't the same thing happen when
the Mod is larger?  No and yes.  Data is physically read from disk in
chunks.  Over the years the frame size in MV environments has closely
followed the physical disk read size (an even disk sector in most cases),
which is why we've seen an evolution from 512 to 1024, 2048, etc.  Disk
drives (and utilization of memory cache and intelligent read-ahead
software) are always far ahead of MV, and in a single read they'll read an
entire track of several contiguous sectors (contiguous frames) so that the
next sequential frames (primary frame of the next group) has probably
already been read into memory by the time the database decides that it has
finished with one group and it needs the next one.  These days that
technology is so far ahead of MV that selective placement of data on disk
just isn't worth the time.  There is so much data in memory, and disk
drives allocate and reallocate data based on errors detected and many other
factors - we can't predict like we used to exactly where the heads are
going to find our data.

 
> Perhaps his age at the time (50?) indicated a respect for the
> incredibly precious resources that he was used to and the disciplines
> that he had to adhere to. In the last 28 years of my MV programming I
> have never recalled having to be so anal as to perform such a
> lower-level observation for such an unmeasurable improvement.

Just for reference, back in the 80's I also used to do that sort of thing
on R83, GA, Microdata, Ultimate, and maybe ADDS or other platforms.  But
when Pick started running on a host OS, all bets were off as some other
kernel or hardware disk controller was now in control of disk access.  The
requirement for doing this was less for performance and more because from
one release to the next, the DBMS environments would have problems frame
faulting for object code, procs, MD entries, etc..

Tony
TG@ removethisNebula-RnD.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Mark Johnson]

I had such an occurrence where someone was creating an additional data-level
file on an existing dict/data file set. So he typed:

CREATE-FILE DATA EXISTINGFILE NEWDATALEVEL 1,1 1,1

assuming that the 1,1 pertained to the dict and the 1,1 applied to the
new datalevel that they were creating. The 1,1 was ignored

While D3 and native systems reply with the base and mod frame numbers of the
new file, it wasn't read by the programmer. But when the new datalevel file
was put into production, the client called in a few weeks as it got
hammered. There was some egg on the face of that programmer, especially
reviewing the TCL-STACK file (big brother) for the typed command.

FYI
Mark Johnson
- Original Message -
From: <[EMAIL PROTECTED]>
To: 
Sent: Thursday, October 19, 2006 11:51 AM
Subject: RE: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM &
RM


> Mark
>
>  >Today's numbers are downright staggering in the MV world.
>
> A couple of weeks ago I had to repair a failed RedBack implementation.
>
> The garbage collection wasn't running, and so their state file had grown
to being a mere 15,000 times undersized.
>
> Strangely enough, this eventually led to corruption and decay. But it must
have been running a long while before it did.
>
> and, yes, I left the tuning manual and garbage collection instructions on
the guy's desk.
>
> 
>
> Brian
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & R M

[Mark Johnson]

You're welcome.

In another magazine that I write for, I've been labeled "The Resident
Curmudgeon". I guess my age shows up not believeing (or wanting to believe)
things that others may get excited about.

Oddly enough I have a brother who writes HTML in Wordpad and despite my
suggestions, he's become pretty profecient with it. I guess the same can be
said for Jurrasic Pick programmers like myself who have lived 100 years in
ED BP ABC with the L22 editor. I now use WED from Accuterm and many on this
forum use other modern tools for managing these text files we call programs.
Some even use vi as their preferred editor.

Using programming tools like SB, GED and the other hamburger helper 4GL's,
we are spared from the tedious nature of the generic MV EDitor. On the other
hand, many people are still supporting and enhancing systems that were
written 10-25 years ago and one could wonder how they could write such
sophisticated applications with *only* the L22 editor. The average age of my
client's systems is 18 years.


I am enjoying using Accuterm with its GUI editor for making VB-looking forms
on top of the standard MV database and haven't been this excited about an MV
product since the creation of the EXECUTE command. Add their Windows Editor
WED and all of the connectivity stuff and sell it for $995 for 50 licenses
and it's a no brainer. All of my clients (except for those still on
Microdata) will be installing Accuterm and I will deliver happiness with the
GUI programs.


Thanks
Mark Johnson
- Original Message -
From: "Ron Sharcott" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, October 19, 2006 12:48 PM
Subject: RE: [U2] VOCLIB and keeping VOC entries Short and Small, IM & R M


> I enjoyed reading that and wanted to say thank you.
>
> Rapid Application Development (RAD) does not have to be sloppy and quick.
If
> slowed down a touch it can start to include a touch of quality. Often RAD
is
> taken to mean "just get it done" when really it means "roll it out when it
> can do the job" and "use prebuilt tools to do the job".
>
> Applications that assist RAD can be bloating if used without a watchful
eye.
> Editing HTML in Word is a prime example of that. At the same rate writing
> 100 pages of HTML using nothing but Notepad is a waste of time.
>
> Its all about balance.
>
> Thank you again.
>
>
> Ron Sharcott (3635)
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson
> Sent: Thursday, October 19, 2006 7:50 AM
> To: u2-users@listserver.u2ug.org
> Subject: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM
>
>
> In observing this thread the words 'page size' caught my eye.
>
> In 1978 I remember a much older programmer working with me at Microdata
> (sic) reading very closely the Basic compiler output generated with the
MAP
> option. Microdata's compiler didn't (doesn't) generate the necessary file
> helpful with debugging programs automatically so you had to specify with
the
> (M option to generate it. It produced the variable table and laid out the
> basic code lines as they were spread out over the object code record.
>
> I recall him reviewing a FOR...NEXT loop that had the FOR part in one
frame
> and the NEXT part in another and he was spending time trying to put
> compilable code (not comments) in front of the FOR section in the hope
that
> the both the FOR and NEXT were in the same frame. This may have had the
> moniker "Frame Faulting". Mainframes called this a Core Dump.
>
> So he would code and compile and review, code and compile and review until
> he felt it was right.
>
> Perhaps his age at the time (50?) indicated a respect for the incredibly
> precious resources that he was used to and the disciplines that he had to
> adhere to. In the last 28 years of my MV programming I have never recalled
> having to be so anal as to perform such a lower-level observation for such
> an unmeasurable improvement. I could never count the number of times I
typed
> the word "BASIC"
>
> I don't advocate sloppy programming or poor file design techniques. But
with
> today's incredibly fast, fast, fast, fast and large, large, large systems,
I
> believe there is also an unmeasurable element to over analyzing the
> tweaking.
>
> While it's easy to take an academic approach to the micro-managing of each
> CPU cycle and disc read, at some time it just really doesn't matter.
Granted
> if you create a file with a mod of 1 and try to cram 10 MB into it, the
> system will accomodate this gross error and reward you with a slower file.
>
> But if the file was created with a mod of 1001 (sic) and it should have
been
> 1401 (sic), how measurably different is the delay with the 40% undersized
> file of 1001? (PS for those who don't know, (sic) means example. Don't
reply
> with lessons on prime numbers. It's just an example).
>
> I tried this years ago on a single user system (multiple user systems are
> much harder to truly measure with the other user's aff

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Mark Johnson]

I stand corrected. I've used (sic) for years and no-one has complained.
Perhaps they didn't know either.

I just don't want someone replying to a post because my editorial example
isn't technically correct, prime-wise. In this case, 3001 is prime but I
don't want to insure that all the other numbers are prime just for a
dissertation. It was for relative difference and an example only.

Thanks
Mark Johnson
- Original Message -
From: "Jeff Schasny" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, October 19, 2006 12:32 PM
Subject: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM


> Much as I hate to make editorial comments on a very nice writeup, I'd
> hate for you to go on misusing [sic].
>
>  From the wikipedia (and correct as far as I have always known):
>
> /*Sic*/ is a Latin  word meaning "thus", "so", or
> "just as that". In writing, it is italicized and placed within square
> brackets   [/sic/]  to indicate that an incorrect or
> unusual spelling, phrase, or other preceding quoted material is a
> verbatim  reproduction of the
> quoted original and is not a transcription error.
>
> This may be used either to show that an uncommon or archaic usage is
> reported faithfully (for instance, quoting the U.S. Constitution
> , "The House of Representatives
>  shall chuse [/sic/] their Speaker...")
> or to highlight an error, often for the purpose of ridicule or irony
> (for instance, "Dan Quayle  famously changed a
> student's spelling to 'potatoe ' [/sic/]"), or otherwise,
> to quote accurately whilst maintaining the reputation of the person or
> organisation quoting its source.
>
> In folk etymology , "sic" is sometimes erroneously
> thought to be an abbreviation of "spelling is correct", "same in copy
> ", "spelled incorrectly", "spelling
> incompetent", "said in context", "stupid in context", "stand incorrect",
> or "spelling intentionally changed", to cite but a few backronyms
> .
>
>
>
> Mark Johnson wrote:
> > But if the file was created with a mod of 1001 (sic) and it should have
been
> > 1401 (sic), how measurably different is the delay with the 40%
undersized
> > file of 1001? (PS for those who don't know, (sic) means example. Don't
reply
> > with lessons on prime numbers. It's just an example).
> >
> [large amounts of stuff trimmed]
>
> --
> ==
>  Jeff Schasny
>  jschasnyATricochetDOTcom
> ==
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

[U2] Mark Shannon/Australia/IBM is out of the office.

[Mark Shannon]

I will be out of the office starting  19/10/2006 and will not return until
23/10/2006.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] VOCLIB and keeping VOC entries Short and Small, IM & R M

[Ron Sharcott]

I enjoyed reading that and wanted to say thank you. 

Rapid Application Development (RAD) does not have to be sloppy and quick. If
slowed down a touch it can start to include a touch of quality. Often RAD is
taken to mean "just get it done" when really it means "roll it out when it
can do the job" and "use prebuilt tools to do the job".

Applications that assist RAD can be bloating if used without a watchful eye.
Editing HTML in Word is a prime example of that. At the same rate writing
100 pages of HTML using nothing but Notepad is a waste of time.

Its all about balance.

Thank you again.


Ron Sharcott (3635)


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson
Sent: Thursday, October 19, 2006 7:50 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM


In observing this thread the words 'page size' caught my eye.

In 1978 I remember a much older programmer working with me at Microdata
(sic) reading very closely the Basic compiler output generated with the MAP
option. Microdata's compiler didn't (doesn't) generate the necessary file
helpful with debugging programs automatically so you had to specify with the
(M option to generate it. It produced the variable table and laid out the
basic code lines as they were spread out over the object code record.

I recall him reviewing a FOR...NEXT loop that had the FOR part in one frame
and the NEXT part in another and he was spending time trying to put
compilable code (not comments) in front of the FOR section in the hope that
the both the FOR and NEXT were in the same frame. This may have had the
moniker "Frame Faulting". Mainframes called this a Core Dump.

So he would code and compile and review, code and compile and review until
he felt it was right.

Perhaps his age at the time (50?) indicated a respect for the incredibly
precious resources that he was used to and the disciplines that he had to
adhere to. In the last 28 years of my MV programming I have never recalled
having to be so anal as to perform such a lower-level observation for such
an unmeasurable improvement. I could never count the number of times I typed
the word "BASIC"

I don't advocate sloppy programming or poor file design techniques. But with
today's incredibly fast, fast, fast, fast and large, large, large systems, I
believe there is also an unmeasurable element to over analyzing the
tweaking.

While it's easy to take an academic approach to the micro-managing of each
CPU cycle and disc read, at some time it just really doesn't matter. Granted
if you create a file with a mod of 1 and try to cram 10 MB into it, the
system will accomodate this gross error and reward you with a slower file.

But if the file was created with a mod of 1001 (sic) and it should have been
1401 (sic), how measurably different is the delay with the 40% undersized
file of 1001? (PS for those who don't know, (sic) means example. Don't reply
with lessons on prime numbers. It's just an example).

I tried this years ago on a single user system (multiple user systems are
much harder to truly measure with the other user's affect). IIRC I had a
file that needed a 3001 (sic) modulo and I loaded it from tape into
different file sizes ranging from 11, 101, the calculated 3001 and even
15001. I performed some crude timing tests, ie sorting, read/re-write etc
and came away with the impression that it really doesn't matter unless it's
tremendously undersized. The 11 size file was the poorest but the 101, 501
and 15001 were suprisingly close to the 'preferred' 3001. IIRC even having
some non-prime modulos near 3001 and it didn't matter either.

I haven't tried this test recently but I can imagine that the results would
be quicker but the shot-group would be the same if not tighter. I don't know
about U2 systems, but D3 systems have long dropped the separation value in
creating files with the assumption of '1'. That closes that chapter on file
calculations.

I can't imagine justifying the process to analyze and re-analyze this today.
Perhaps I'm wrong and someone managing a 10,000 user system will babble
about every precious CPU. But for the rest of us it is an entertaining
distraction that would be hard to cost-justify. We don't have a 10 MB hard
drive system supporting 16 users with 32K of core memory anymore. Today's
numbers are downright staggering in the MV world.

My 101,1 cents
Mark Johnson

- Original Message -
From: "Anthony W. Youngman" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, October 18, 2006 5:06 AM
Subject: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM


> In message 
> <[EMAIL PROTECTED]>, Adrian 
> Merrall <[EMAIL PROTECTED]> writes
> >> And on, and on, until the particular bit of data is found. So... 
> >> (this being one of the overwhelmingly elegant things about the
> >> Pickuverse) this means that in a properly sized hashed file NO 
> >> MATTER HOW BIG it only takes one disk read t

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Jeff Schasny]

Much as I hate to make editorial comments on a very nice writeup, I'd 
hate for you to go on misusing [sic].


From the wikipedia (and correct as far as I have always known):

/*Sic*/ is a Latin  word meaning "thus", "so", or 
"just as that". In writing, it is italicized and placed within square 
brackets   [/sic/]  to indicate that an incorrect or 
unusual spelling, phrase, or other preceding quoted material is a 
verbatim  reproduction of the 
quoted original and is not a transcription error.


This may be used either to show that an uncommon or archaic usage is 
reported faithfully (for instance, quoting the U.S. Constitution 
, "The House of Representatives 
 shall chuse [/sic/] their Speaker...") 
or to highlight an error, often for the purpose of ridicule or irony 
(for instance, "Dan Quayle  famously changed a 
student's spelling to 'potatoe ' [/sic/]"), or otherwise, 
to quote accurately whilst maintaining the reputation of the person or 
organisation quoting its source.


In folk etymology , "sic" is sometimes erroneously 
thought to be an abbreviation of "spelling is correct", "same in copy 
", "spelled incorrectly", "spelling 
incompetent", "said in context", "stupid in context", "stand incorrect", 
or "spelling intentionally changed", to cite but a few backronyms 
.




Mark Johnson wrote:

But if the file was created with a mod of 1001 (sic) and it should have been
1401 (sic), how measurably different is the delay with the 40% undersized
file of 1001? (PS for those who don't know, (sic) means example. Don't reply
with lessons on prime numbers. It's just an example).
  

[large amounts of stuff trimmed]

--
==
Jeff Schasny
jschasnyATricochetDOTcom
==
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[brian]

Mark

 >Today's numbers are downright staggering in the MV world. 

A couple of weeks ago I had to repair a failed RedBack implementation.

The garbage collection wasn't running, and so their state file had grown to 
being a mere 15,000 times undersized.

Strangely enough, this eventually led to corruption and decay. But it must have 
been running a long while before it did.

and, yes, I left the tuning manual and garbage collection instructions on the 
guy's desk.



Brian
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Mark Johnson]

In observing this thread the words 'page size' caught my eye.

In 1978 I remember a much older programmer working with me at Microdata
(sic) reading very closely the Basic compiler output generated with the MAP
option. Microdata's compiler didn't (doesn't) generate the necessary file
helpful with debugging programs automatically so you had to specify with the
(M option to generate it. It produced the variable table and laid out the
basic code lines as they were spread out over the object code record.

I recall him reviewing a FOR...NEXT loop that had the FOR part in one frame
and the NEXT part in another and he was spending time trying to put
compilable code (not comments) in front of the FOR section in the hope that
the both the FOR and NEXT were in the same frame. This may have had the
moniker "Frame Faulting". Mainframes called this a Core Dump.

So he would code and compile and review, code and compile and review until
he felt it was right.

Perhaps his age at the time (50?) indicated a respect for the incredibly
precious resources that he was used to and the disciplines that he had to
adhere to. In the last 28 years of my MV programming I have never recalled
having to be so anal as to perform such a lower-level observation for such
an unmeasurable improvement. I could never count the number of times I typed
the word "BASIC"

I don't advocate sloppy programming or poor file design techniques. But with
today's incredibly fast, fast, fast, fast and large, large, large systems, I
believe there is also an unmeasurable element to over analyzing the
tweaking.

While it's easy to take an academic approach to the micro-managing of each
CPU cycle and disc read, at some time it just really doesn't matter. Granted
if you create a file with a mod of 1 and try to cram 10 MB into it, the
system will accomodate this gross error and reward you with a slower file.

But if the file was created with a mod of 1001 (sic) and it should have been
1401 (sic), how measurably different is the delay with the 40% undersized
file of 1001? (PS for those who don't know, (sic) means example. Don't reply
with lessons on prime numbers. It's just an example).

I tried this years ago on a single user system (multiple user systems are
much harder to truly measure with the other user's affect). IIRC I had a
file that needed a 3001 (sic) modulo and I loaded it from tape into
different file sizes ranging from 11, 101, the calculated 3001 and even
15001. I performed some crude timing tests, ie sorting, read/re-write etc
and came away with the impression that it really doesn't matter unless it's
tremendously undersized. The 11 size file was the poorest but the 101, 501
and 15001 were suprisingly close to the 'preferred' 3001. IIRC even having
some non-prime modulos near 3001 and it didn't matter either.

I haven't tried this test recently but I can imagine that the results would
be quicker but the shot-group would be the same if not tighter. I don't know
about U2 systems, but D3 systems have long dropped the separation value in
creating files with the assumption of '1'. That closes that chapter on file
calculations.

I can't imagine justifying the process to analyze and re-analyze this today.
Perhaps I'm wrong and someone managing a 10,000 user system will babble
about every precious CPU. But for the rest of us it is an entertaining
distraction that would be hard to cost-justify. We don't have a 10 MB hard
drive system supporting 16 users with 32K of core memory anymore. Today's
numbers are downright staggering in the MV world.

My 101,1 cents
Mark Johnson

- Original Message -
From: "Anthony W. Youngman" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, October 18, 2006 5:06 AM
Subject: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM


> In message
> <[EMAIL PROTECTED]>, Adrian
> Merrall <[EMAIL PROTECTED]> writes
> >> And on, and on, until the particular bit of data is found.
> >> So... (this being one of the overwhelmingly elegant things about the
> >> Pickuverse) this means that in a properly sized hashed file NO MATTER
> >> HOW BIG it only takes one disk read to get to any record given a known
> >> key. Ask your local Oracle/Sybase/Informix/SQL Server DBA if they can
do
> >> that. Stand back though, they tend to sputter alot.
> >
> >But won't this only work if your data fits into the modulo that
> >matches your page size?  If your data is lumpy and doesn't nicely fit
> >into the page size/file modulo selected you get level 1overflow and
> >more disk IO.
> >
> The stats I've come across (yes, they're old, they came from Prime) say
> that PROVIDED Adrian's "properly sized" caveat is followed, even when
> you have level 1 overflow and lumpy data, your 1 merely increases to an
> average of 1.05. In other words, 19 out of 20 attempts still hit first
> time...
>
> Cheers,
> Wol
> --
> Anthony W. Youngman <[EMAIL PROTECTED]>
> 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
> thimble. 'What *is* he?' sai

Re: RE: [U2] Roman Numerals

[Mark Johnson]

I recall this in the D3 manual and wondered why would anyone have such a
thing.

A=123
PRINT OCONV(A,"U0033")

yields CXXIII

I guess it was for incrementing chapters or some other formal/outline number
sequences. I don't know what the maximum number is but OCONV("25000","U0033)
yields M. 50,000 and 100,000 didn't work.

My XIV cents.
Mark Johnson




- Original Message -
From: <[EMAIL PROTECTED]>
To: 
Sent: Thursday, October 19, 2006 4:25 AM
Subject: RE: RE: [U2] Roman Numerals


> The Chinese Year has always been wrong, since it is still assumes 01 Jan
as the start day of the year. I think I reported that to VMARK about 20
years ago...
>
> Brian
>
> >David A. Green wrote:
> >>> Does any one have a Digit to Roman Numeral converter they would like
> >>> to share?
> >
> >Ron White responded:
> >> How about ICONV/OCONV with the NR function code.  Look in the
> >> Basic Reference Manual index for roman numerals.
> >
> >A search on CDP reveals a couple interesting tidbits on this.
> >
> >According to Oliver Elphick, the NR conversion in Universe "uses a change
> >of alphabetic case to represent multiplication by 1000, so v=5 but
V=5000."
> >
> >According to Tom Rauschenbach, [sic] "the author of the NR conversion
> >(someone named Hal) says
> >that there was a reason for the upper/lower case distinction, but he
can't
> >remember what it was.  He also claims that the Chinese New Year is
wrong."
> >(I have no idea what that means.)
> >
> >The D3 equivalent (as if anyone here cares) is the user exit U33.
> >And the Reality equivalent is conversion MCDR.
> >R83 had conversion MCR.
> >
> >So many standards, so little time...
> >T
> >---
> >u2-users mailing list
> >u2-users@listserver.u2ug.org
> >To unsubscribe please visit http://listserver.u2ug.org/
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

[U2] wIntegrate and Dynamic Connect

[Bob Modrich]

With wIntegrate you can call a subroutine called:  WIN.PCRUN which allows
you to launch an executable on the client machine. Dynamic Connect does not
support or allow the execution of  WIN.PCRUN. Has anyone developed a method
or program which can be called from a basic program to launch an executable,
when using dynamic connect.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: RE: [U2] Roman Numerals

[brian]

The Chinese Year has always been wrong, since it is still assumes 01 Jan as the 
start day of the year. I think I reported that to VMARK about 20 years ago...

Brian

>David A. Green wrote:
>>> Does any one have a Digit to Roman Numeral converter they would like
>>> to share? 
>
>Ron White responded:
>> How about ICONV/OCONV with the NR function code.  Look in the
>> Basic Reference Manual index for roman numerals.
>
>A search on CDP reveals a couple interesting tidbits on this.
>
>According to Oliver Elphick, the NR conversion in Universe "uses a change
>of alphabetic case to represent multiplication by 1000, so v=5 but V=5000."
>
>According to Tom Rauschenbach, [sic] "the author of the NR conversion
>(someone named Hal) says 
>that there was a reason for the upper/lower case distinction, but he can't
>remember what it was.  He also claims that the Chinese New Year is wrong."
>(I have no idea what that means.)
>
>The D3 equivalent (as if anyone here cares) is the user exit U33.
>And the Reality equivalent is conversion MCDR.
>R83 had conversion MCR.
>
>So many standards, so little time...
>T
>---
>u2-users mailing list
>u2-users@listserver.u2ug.org
>To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] [UV] is a file 32bit or 64bit?

[Womack, Adrian]

Something interesting I just noticed:

If I create a file and resize it to 64bit and then create alternate keys
(with CREATE.INDEX) the alternate key file (I_filename/INDEX.000) is
also created as 64bit.

BUT, if I add the alternate keys BEFORE resizing to 64bit, the AK file
is left as a 32bit file.

As a 64bit file, the data portion can now contain many, many more
records than a 32bit file. So if the file has a number of different
alternate keys, it could be possible to blow the size of the INDEX.000
file.

So, I guess it may be best to delete and re-create the AKs after
converting to 64bit. Thoughts?

Adrian





DISCLAIMER:
Disclaimer.  This e-mail is private and confidential. If you are not the 
intended recipient, please advise us by return e-mail immediately, and delete 
the e-mail and any attachments without using or disclosing the contents in any 
way. The views expressed in this e-mail are those of the author, and do not 
represent those of this company unless this is clearly indicated. You should 
scan this e-mail and any attachments for viruses. This company accepts no 
liability for any direct or indirect damage or loss resulting from the use of 
any attachments to this e-mail.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/