What would you like to see Rocket put into D3?

[Eugene Perry]

Now that Rocket is going to have the U2 products as well as D3, mvBase and mvEnterprise this might be an opportunity for some things to be put into the "D3" product.

 

I personally would like to see the OPENSEQ commands put in so that we do not have to use C% commands to do that.

 

It would also be nice to have @ID and the F1, etc be used in addition to the *A0 type structure.

 

What would you like to see?

 

Thanks

 

Eugene

[CDMI - Steve T]

yep - those suggestions would be postive for me as well

 

Steve Trimble

Computerized Data Mgmt Inc
2705 Justin Matthews Dr
N Little Rock, AR 72116
(501) 615-8674 09:00am - 6:00pm CST

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Art Martz]

On 10/24/2013 03:29 PM, Eugene Perry wrote:
> Now that Rocket is going to have the U2 products as well as D3, mvBase and mvEnterprise this might be an opportunity for some things to be put into the "D3" product.
> I personally would like to see the OPENSEQ commands put in so that we do not have to use C% commands to do that.

You don't need the OPENSEQ, you can just specify the file path in the open statement, and treat it like any other Pick read or write.
Art

[CDMI - Steve T]

Art - in our D3/Linux environment, D3 died on the vine using that technique when 'creating' the file become 2GB.

i actually decided for speed, etc. to create multiple files around 1GB and when done 'cat' them all together as 1 file.

works quite well.

 

here is some code i wrote:

 

SUBROUTINE WRITEUNIX.SUB(ERRMSG,OPENMODE,STRG,OUTFL,UNIXSQNO)
!
* 10-31-12 smt unix file write routine - send OUTFL as: /var/xxx/tmp/slsPORTinfo
*          this software will make the file as: /var/xxx/tmp/slsPORTinfo_SEQNO
*          openmode can be TRUNC or APPEND
*          len(STRG) should be less than 99,999,999
*********************************
*
* THIS PGM MUST BE FLASH COMPILED
*
*********************************
!
* modifications:
* 02-27-13 smt if size > 1GB create
!
$OPTIONS ext
* CASING ON
*
**** INCLUDE DM,BP,UNIX.H FCNTL.H
*
* Open flags
* These flags are defined in decimal and must be added together
* to form various combinations
*
* [01] 21Apr91:es: Added O$NDELAY
* [02] 18Nov91:es: Added O$APPEND, O$SYNC
* [03] 26Aug93:es: Changed NDELAY for AIX only
* [04] 01Jun94:es: Piut in all upper case (act 15097)
* [05] 26Sep96:hy: Added case for Linux
* [06] 01Mar00:es: [23808] Added case for NT
* [07] 07Jun00:tr: [?] Fixed AIX
* [08] 05Nov02:tw: [27773] added open() mode(permission) options
* [09] 20Nov02:tw: remove [08] - defined in mode.h already
*
FCNTL.SYS=SYSTEM(100)        ;* <<<< Have to use this...
*
*** casing off
*
* Flag values accessible to open(2)
EQU O$RDONLY TO 0
EQU O$WRONLY TO 1
EQU O$RDWR   TO 2
*
* Flag values accessible only to open(2)
* [05] LINUX has special value
IF INDEX(FCNTL.SYS,'LINUX',1) THEN
 O$APPEND = 1024     ;* append to end of file
 O$SYNC   = 4096     ;* sync write
 O$CREAT  = 64       ;*  open with file create (uses third open arg)
 O$TRUNC  = 512      ;* open with truncation
 O$EXCL   = 128      ;* exclusive open
END ELSE
 O$APPEND = 8        ;* append to end of file
 O$SYNC   = 16       ;* sync write
 O$CREAT  = 256      ;*  open with file create (uses third open arg)
 O$TRUNC  = 512      ;* open with truncation
 O$EXCL   = 1024     ;* exclusive open
END
*
* [03] AIX has special value
IF INDEX(FCNTL.SYS,'AIX',1) THEN
 O$NDELAY =  32768    ;* no delay on open/read
* [05] LINUX has special value
END ELSE
 IF INDEX(FCNTL.SYS,'LINUX',1) THEN
  O$NDELAY =  2048     ;* no delay on open/read
 END ELSE
  O$NDELAY =  4        ;* no delay on open/read
 END
END
*
* [06] Overwrite NT values
* ------------------------
IF INDEX(FCNTL.SYS,'NT;',1) THEN
 O$TEXT = 16384       ;* Text mode
 O$BINARY=32768       ;* Binary mode
END ELSE
* Non existent for non-nt
 O$TEXT = 0           ;* Text mode
 O$BINARY=0           ;* Binary mode
END
*
* File descriptor flags used for fcntl()
EQU FD$CLOEXEC      TO 1   ;* Close this file during exec
*
* fcntl() requests
EQU  F$DUPFD    TO 0   ;* Duplicate fildes
EQU  F$GETFD    TO 1   ;* Get fildes flags
EQU  F$SETFD    TO 2   ;* Set fildes flags
EQU  F$GETFL    TO 3   ;* Get file flags
EQU  F$SETFL    TO 4   ;* Set file flags
EQU  F$GETLK    TO 5   ;* Get file lock
EQU  F$SETLK    TO 6   ;* Set file lock
EQU  F$SETLKW   TO 7   ;* Set file lock and wait
*****
*
**** INCLUDE DM,BP,UNIX.H MODE.H
!
* File mode bits. These masks are defined in decimal and must be
* added together.
*  (stat) st$mode bit values
*
* [01] 01Mar00:es: [23808] Added NT defines
* [02] 03Mar00:es: [23808] Fixed typo in S$IWRITE
* [03] 21May10:tr: [34402] Some arrogant individual at Microsoft decided
*                          to change the standard and abort if execute
*                          permissions are used.
*
D3.IMP = SYSTEM(38)<3>
*
EQU S$IFMT      TO 61440       ;* type of file
EQU S$IFREG     TO 32768       ;*   regular
EQU S$IFDIR     TO 16384       ;*   directory
EQU S$IFBLK     TO 24576       ;*   block special
EQU S$IFCHR     TO 8192        ;*   character special
EQU S$IFIFO     TO 4096        ;*   fifo
EQU S$ISUID     TO 2048        ;* set user id on execution
EQU S$ISGID     TO 1024        ;* set group id on execution
*
* /usr/group definitions
EQU S$IRUSR     TO 256         ;* read permission: owner
EQU S$IWUSR     TO 128         ;* write permission: owner
EQU S$IXUSR     TO 64          ;* execute/search permission: owner
EQU S$IRGRP     TO 32          ;* read permission: group
EQU S$IWGRP     TO 16          ;* write permission: group
EQU S$IXGRP     TO 8           ;* execute/search permission: group
EQU S$IROTH     TO 4           ;* read permission: other
EQU S$IWOTH     TO 2           ;* write permission: other
EQU S$IXOTH     TO 1           ;* execute/search permission: other
*
* [01] NT mode
* ------------
IF D3.IMP = 12 THEN
 S$IREAD   =    256           ;* read only
 S$IWRITE  =    128           ;* write only
 S$IRWXU   = S$IRUSR+S$IWUSR  ;* [03] read,write perm: owner
 S$IRWXG   = S$IRGRP+S$IWGRP  ;* [03] read,write perm: group
 S$IRWXO   = S$IROTH+S$IWOTH  ;* [03] read,write perm: other
END ELSE
* Dummy values for UNIX
 S$IREAD   =    S$IRUSR       ;* read only
 S$IWRITE  =    S$IWUSR       ;* write only
 S$IRWXU   = S$IRUSR+S$IWUSR+S$IXUSR ;* read,write,execute perm: owner
 S$IRWXG   = S$IRGRP+S$IWGRP+S$IXGRP ;* read,write,execute perm: group
 S$IRWXO   = S$IROTH+S$IWOTH+S$IXOTH ;* read,write,execute perm: other
END
*****
*
EQUATE CR TO CHAR(13)
EQUATE LF TO CHAR(10)
!
100 *
!
UPDPATH = OUTFL:"_":UNIXSQNO
*
IF OPENMODE = \TRUNC\ THEN
* FD = %OPEN(UPDPATH,O$RDWR+O$TRUNC) ; * read/write append
* IF FD < 0 THEN
*  FD = %OPEN(UPDPATH,O$CREAT,S$IRWXU+S$IRWXG+S$IRWXO) ; * create and set user read/write
*  IF FD < 0 THEN
*   ERRMSG = \%OPEN $TRUNC and $CREAT \:UPDPATH:\ failed.\
*   RETURN
*  END
* END
 CMD = \!rm -f \:UPDPATH
 EXECUTE CMD
 CMD = \!touch \:UPDPATH
 EXECUTE CMD
* FD = %OPEN(UPDPATH,O$RDWR+O$TRUNC) ; * read/write append
 FD = %OPEN(UPDPATH,O$APPEND+O$RDWR) ; * read/write append
 IF FD < 0 THEN
  ERRMSG = \removal, touch, %OPEN,RDWR,TRUNC failed for \:UPDPATH
  RETURN
 END
* CRT \trunc of \:UPDPATH
END ELSE
 FD = %OPEN(UPDPATH,O$APPEND+O$RDWR) ; * read/write append
 IF FD < 0 THEN
  ERRMSG = \%OPEN $APPEND and $RDWR \:UPDPATH:\ failed. ABORT.\
  RETURN
 END
* CRT \append to \:UPDPATH
END
*
*** get size
*
FLSIZE = %FSIZE(FD)
IF FLSIZE > "1000000000" THEN ; * greater than 1GB, (1000000000) create seqno file
 DUMMY = %CLOSE(FD)
 DONE = 0
 LOOP UNTIL DONE DO
  UNIXSQNO+= 1
  CHKFL = OUTFL:"_":UNIXSQNO
  FD = %OPEN(CHKFL,O$APPEND+O$RDWR) ; * read/write append
  IF FD < 0 THEN ; * it's NOT there, so create
   DONE = 1 ; OPENMODE = \TRUNC\
  END ELSE
   DUMMY = %CLOSE(FD)
  END
 REPEAT
 GOTO 100
END
*
LGSTRG = LEN(STRG)
*CRT \writeunix.sub len(strg) \:OCONV(LGSTRG,"MD0,")
FOR II = 1 TO LGSTRG STEP 10000
 W.DTA = SWAP(STRG[II,10000],@AM,LF)
 LG = LEN(W.DTA)
 IF %WRITE(FD,W.DTA,LG) < LG THEN
  ERRMSG = \could NOT %WRITE - ALL data has NOT been written\
  II = 99999999
 END
NEXT II
*
DUMMY = %CLOSE(FD)
*
RETURN
*
END

 

Steve Trimble

Computerized Data Mgmt Inc
2705 Justin Matthews Dr
N Little Rock, AR 72116
(501) 615-8674 09:00am - 6:00pm CST

From: Art Martz <artsm...@gmail.com>
To: mvd...@googlegroups.com

Sent: Thursday, October 24, 2013 2:57 PM
Subject: [mvdbms] Re: What would you like to see Rocket put into D3?

On 10/24/2013 03:29 PM, Eugene Perry wrote:

Now that Rocket is going to have the U2 products as well as D3, mvBase and mvEnterprise this might be an opportunity for some things to be put into the "D3" product.
I personally would like to see the OPENSEQ commands put in so that we do not have to use C% commands to do that.

You don't need the OPENSEQ, you can just specify the file path in the open statement, and treat it like any other Pick read or right.
Art

[Scott Ballinger]

Here are some things I would like to see moved from D3 to Universe:

1. Case insensitivity.

2. Running counter on select, i.e. (t option.

3. "cd" (change directory).

4. Direct handling of O/S files and directories, without having to create F pointers (e.g. open "/usr/local/tmp/" to ult then...  or  list /usr/local/tmp/  or  select /usr/local/tmp/  etc etc.).

5. Flash compiler.

6. I prefer the D3 btree index functions (root, key) but maybe I'm just used to them.

Others?

I do like the NONULLS index option in Universe. That would be nice to have in D3.

Re: openseq, I find the %creat & %write process very easy to use. I only use the %read on really really huge files, normally I just "qselect /usr/local/ myfile" (note space before myfile!)  then readnext line else exit.  Or if I have already cd'd to the appropriate directory, I use "qselect unix:. myfile".

/Scott Ballinger

Pareto Corporation

Edmonds WA USA

206 713 6006

[Ross Ferris]

I don't think you NEED the flash compiler --> UV compiled code seems to be around as fast as Flashed D3 code most of the time 

[Anthony Youngman]

What do you mean by F1? If you mean D-types in dictionaries, then that
might require work (I don't know D3).

But if you mean using F1 etc in a list command, can't you do that
already? All INFORMATION-derived command processors scan the VOC -
doesn't the Pick one do the same? Can't you just put a DICT entry in the
MD and have the command processor pick it up?

Cheers,
Wol

[Eugene Perry]

Yes, it would be easy to copy *A0 to @ID and the *A0 to F1 etc.

 

The problem is  that you would have to do that everytime you went to a new D3 system.  It would be a lot better to have Rocket do that as a default.  It really would not be difficult for them to do that.

[Anthony Youngman]

On 25/10/13 14:59, Eugene Perry wrote:
> Yes, it would be easy to copy *A0 to @ID and the *A0 to F1 etc.
>
> The problem is that you would have to do that everytime you went to a
> new D3 system. It would be a lot better to have Rocket do that as a
> default. It really would not be difficult for them to do that.

But would it be any use to you? IME as a long time user, the supplied
fields (F1 to F10) are not that much use. They're only useful for
quick-n-dirty (FMT=10L isn't very helpful) and the ones I want usually
aren't there anyway - most FILEs I work with have a lot more than ten
fields.

About the only thing they're really useful for is a template for when I
need eg F132 :-) I usually find myself creating them as required.

Does D3 have the equivalent of UV's NEWACC file? Just shove a couple
(maybe F1 and F2) in there when you install D3, and create the rest as
needed. As I say, even us who have them by default mostly have to create
them as required.

Cheers,
Wol

[Dick Thiot]

Didn't NEWACC originate with Pick R77?

On Fri, Oct 25, 2013 at 10:08 AM, Anthony Youngman <wolw...@gmail.com> wrote:

On 25/10/13 14:59, Eugene Perry wrote:Does D3 have the equivalent of UV's NEWACC file? Just shove a couple

[frosty]

Time Bomb!  (Tick, Tick, RIP Dick Pick)

-- 

frosty

[Scott Ballinger]

D3 has *a1, *a2 etc in the md (copied there from dm,newac,) but there are totally not needed, because in access D3 interprets a1, a2 .... a9999 as the appropriate attribute number on the fly. And they use the "lx" justification- which automatically expands the field width up to the screen width. (Another great D3 feature [tx, lx] that would be nice to see in Universe.)

/Scott

[Scott Ballinger]

On Thursday, October 24, 2013 9:36:46 PM UTC-7, Ross Ferris wrote:

I don't think you NEED the flash compiler --> UV compiled code seems to be around as fast as Flashed D3 code most of the time 

True, the UV compiled BASIC is comparable in speed to the flashed D3 BASIC, but... wouldn't it be nice to see the same order of magnitude improvement that you get when you flash D3 BASIC if you could flash UV BASIC!

/Scott

[fwinans]

The first computer language I was exposed to was APL;  computing's never been as much fun,
ever since.  I don't think anything Rocket might do will help much with that.  Mommas, don't let
your babies grow up to use APL...

It would really be too hard to achieve, but still pleasant if you some day could
   a)  put 'external' subroutines' source code  at the tail end of sole calling program's source code item
   b)  EXECUTE  a program in basic with an optional seting to not molest an active select
        list or stacked input data or commands
   c)  signal another logged in user's program, or divert a text stream stream to/from them
   d)  have commas in list-file-stats output  numbers,  
        or give  list-file-stats  a verbose form showing   the full  mm/dd/yy  and errors file item id
   e)  make personal annotations to our own copy of  HELP command's entries
   f)   read back a d3/nt file-save tape from d3/linux even if they didn't cut the tape with helpful
        option letters.
  

I see d3  9.x gives you the first two {telnet-based, but not ssh} connections from each desk for
just one user license consumed.  It's lame, but I'm actually jealous, being a rabid  ssh  advocate...

On Thursday, October 24, 2013 1:29:42 PM UTC-6, Eugene Perry wrote:

[jes]

On Saturday, October 26, 2013 4:03:39 PM UTC-4, fwinans wrote:

[snip]

 

  e)  make personal annotations to our own copy of  HELP command's entries

 

[snip]

By its original design and implementation, that was always possible.

I created it as a file, using the Update Processor. The idea was that everyone could update it, 

saving time by eliminating that whole sequence of putting it into the documentarian's in-basket

and perhaps in some future iteration it might show up.

But when I left it behind in 1991, they fell on it like locusts.

Dick appointed a team to "nork" it (We'll save that for another time. It's heinous.), removing

all that pesky, unnecessary stuff like examples, warnings, cross-references (like an HTML

link, 3 years before the Web) and white space, among others.

In the fullness of time, the documentarians managed to extract (some) of the data,

moving it back into some word processing revision cycle model and thus buying 

themselves some job security by eliminating the whole egalitarian thing.

That was the death knell for what became known as "Ref".

I couldn't be happier that D3 has been removed from the hands of Rick Koe and Co.

We can only hope that Rocket will put some effort into doing for the current

docs what I did for them all those years ago.

Hey Rocket, if you're listening, I would be happy to do it again.

JonSisk.com

jes.com

 

[Ross Ferris]

THAT is unlikely (nice, but unlikely!!)

[fwinans]

Thanks, Dude!  HELP has been a real butt-saver when making house calls,
and that is _after_ they worked it over, from what you say.

[jes]

On Monday, October 28, 2013 9:39:09 PM UTC-4, fwinans wrote:

Thanks, Dude!  HELP has been a real butt-saver when making house calls,
and that is _after_ they worked it over, from what you say.

You are most welcome. Thank you for that.

To be fair, they did eventually move a version of it to HTML and exposed it to the Web.

This was extremely useful when teaching in Europe a couple months ago.

My original data design from 1990 was still apparent.

From the intel I have picked up, it may not be up to date.

But with roots reaching back to the 1970's (and the 60's if you count the Editor),

the core of the material is there.

And if you access it with your smart phone, we have come full circle to 

The Pick Pocket Guide (1981).

Pretty sure I can dodge the AD tag issue on this post, since nothing mentioned

here is technically for sale.

Cheers,

j.

[fwinans]

e) often you want to have a basic program do get-list mylist    ;  chain "some_tcl_command"
     which is, of course, a one-way ticket.   Get-list verb needs a (D  option letter that means
  "do the get-list but also delete that list to tidy-up"  

[Ross Ferris]

Write your own if this is something you REALLY want to do.

About 5 lines of code for your own GET-LIST-THEN-DELETE (or maybe GET-LISTD) verb .... not a biggie

[fwinans]

Say I did make such a tool, naming it grabzap in my bp file;
    grabzap can execute a get-list  and that's ok, but then when it goes to delete-list it the active list
    dies since you're doing an execute within a basic program.  Heck, just doing a   stop   command or 'falling off the end' of the
    grabzap program is going to end the active list, unless you end the program with a 'chain' command of some sort that itself
    results in an active select list.  For a reasonably short list you could CHAIN to a SELECT command that enumerates the ids
    desired on the SELECT command line, but I don't see that working for a 100,000 item list, somehow.  Maybe grabzap should
    CHAIN to a get-list  after having launched a background job that sleeps 5 seconds and then deletes the list...?   Messy.

[Scott Ballinger]

Cleaning up the pointer-file is a good thing. I use the "yupt"  processing code in dict pointer-file <8> so that there is a timestamp on every pointer-item, then a housekeeping program selects the pointer-items that are over NNN days old and deletes them. Also, huge pointer-items (millions of items) will cause the D3 t-verify to suck up vast quantities of temporary overflow, so that same housekeeping program select items in the pointer-file that are greater than 799,999,999 bytes (20,000 frames).

/Scott Ballinger

Pareto Corporation

Edmonds WA USA

203 713 6006

[Kevin Powick]

On Wednesday, 20 November 2013 12:03:56 UTC-5, Scott Ballinger wrote:

 greater than 799,999,999 bytes (20,000 frames).

Maybe I'm missing something, but I thought frames were 4K. If so, shouldn't that be about 200,000 frames?  Or did you mean ~ 80MB instead of 800MB?

--

Kevin Powick

[Scott Ballinger]

Oops, you are correct. I meant 200,000 frames.

/Scott

[Ross Ferris]

open "","pointer-file" to fv.pointer-file then

 delete fv.pointer-file,listname

end

--> would seem like a simple solution to me ... and if you save lists in other files, then adjust to suit

[fwinans]

The deletion via exec or via basic DELETE statement on an opened file handle is not the sticky point;
the sticky point is that an active select list from, say,  Grabzap doing an  execute "select myfile sampling 3"
produces an external select list that itself gets   ENDed by the basic program grabzap wrapping up normally.
If instead grabzap does that select as a CHAIN "Select myfile sampling 3"  the select list survives past end
of Grabzap execution, but forcing the vital step into a  CHAIN statement doesn't leave you breathing room to
also delete the pointer file item afterwards.  You could delegate the removal to a phantom job with a leading
SLEEP command, or manufacture an ad-hoc proc/macro to CHAIN to, but that seems a bit strained...

[Ross Ferris]

OK, here are all 5 lines of the working program

01 tclread command

02 listname = field(command," ",2)

03 execute "get-list ":listname

04 open "","pointer-file" to pf then delete pf,listname

05 chain "p":@vm:"select":@vm:"p"

Nasty I know, but you get what you pay for :-)

FWIW in our R5 application we tend to generate list names on the fly & delete at the end of processing with a DELETE-LIST --> that way, if bad things happen mid way through, we still have our LIST to re-process stuff in same order (helps with re-runability)

There are a few things I'd like to be able to do "better" in D3/UV, but the vast majority of things can be done now with a nip & tuck ... maybe not neat, but gets the job done

[Kevin Powick]

On Thursday, 24 October 2013 15:29:42 UTC-4, Eugene Perry wrote:

Now that Rocket is going to have the U2 products as well as D3, mvBase and mvEnterprise this might be an opportunity for some things to be put into the "D3" product.

(1) Add user-defined functions, i.e. subroutines with assignable return value.  Should allow both internal and external definition.  Example:

BP, CALC.AREA

FUNCTION CALC.AREA(LENGTH, WIDTH)
   AREA = LENGTH * WIDTH
   RETURN AREA
END

BP, MYPROG
CRT CALC.AREA(3, 5)
END

(2) Add several new processing codes for date types. e.g ISO 8601 (YYYY-MM-DD)


(3) Open the OSFI to allow developers to write their own drivers for new types of HOSTS entries.

--

Kevin Powick

[Ross Ferris]

(3) Open the OSFI to allow developers to write their own drivers for new types of HOSTS entries.

+1

[fwinans]

You can simplify that to just 
    chain   'select'

Turns out I was wrong, the command you chain to must
  Either  create an active select list,
  Or       at least leave a list active that was active when it started.

But yes, you were quite right, and D3 does not in fact have any
problem with both fetching and deleting a saved list name.

For about the last 8 or 15 years {?} D3 has had a _neat_  feature that
an active select list stays active if the current verb bombs,
so you can try again if you fatfingered a verb while list active.

Your example has 'stacked'  just the one command  'Select'
that is missing a filename, hence bombs the verb {but the error msg
gets hushed up.  CHAINing to a random string that is not an item id
in MD works but this time you DO get an error message.  CHAIN to
a proc or macro that doesn't END a select list works too -- like a
PROC with just   C comment lines, or a macro with just  one line
bearing  N.   REM is {now} a basic program, so it _is_ a list-ENDing verb...}   

By the way, did you ever notice how in a sense "DX'ing a file dict, as for
example dict  dm,object.queue,   will effectively "DX" the data section,
but  "DY"ing the dict doesn't affect the data section...?   I seem to have
developed a GFE in just that very file recently...  Man I just love using
pseudo-floppies instead of real physical tape drives!  No more 'washboarding'...

[fwinans]

You could _kind_ of do this with a preprocessor, if you refrained from using the function in 'complicated' ways like
as part of FOR  or  UNTIL  statements or CONVERT statements. But compile errors and runtime basic debugger
lines would show the 'mangled' variable names in the function definition section, which would be confusing.
Heck, even handling   IF  flag1 THEN IF flag2 AND (CALC.AREA(3, 5) > 7) THEN  etc    would be a booger...

On Wednesday, November 27, 2013 10:51:23 PM UTC-6, Kevin Powick wrote:

On Thursday, 24 October 2013 15:29:42 UTC-4, Eugene Perry wrote:

Now that Rocket is going to have the U2 products as well as D3, mvBase and mvEnterprise this might be an opportunity for some things to be put into the "D3" product.

(1) Add user-defined functions, i.e. subroutines with assignable return value.  Should allow both internal and external definition.  Example:

BP, CALC.AREA

FUNCTION CALC.AREA(LENGTH, WIDTH)
   AREA = LENGTH * WIDTH
   RETURN AREA
END

BP, MYPROG
CRT CALC.AREA(3, 5)
END

--

Kevin Powick

[Kevin Powick]

On Friday, 29 November 2013 16:10:42 UTC-5, fwinans wrote:

You could _kind_ of do this with a preprocessor, if you refrained from using the function in 'complicated' ways like
as part of FOR  or  UNTIL  statements or CONVERT statements. But compile errors and runtime basic debugger
lines would show the 'mangled' variable names in the function definition section, which would be confusing.

User-defined Functions are in QM and, I believe, Universe.  Let's get them into D3.

--

Kevin Powick 

[Anthony Youngman]

Yes they are in UniVerse. I didn't use them much but they are useful.

In UV the keywords SUBROUTINE, PROGRAM, and FUNCTION are (pretty much)
interchangeable, iirc.

In the caller you use the DEFFUN statement to declare it as a function,
and in the callee, you declare the return value as the first argument.

So in the caller

DEFFUN CALC.AREA( XWID, YLEN)

BOX.AREA = CALC.AREA( 4, 3)

and in the callee

SUBROUTINE CALC.AREA( AREA, XWID, YLEN)
AREA = XWID * YLEN
RETURN

Cheers,
Wol

[Ross Ferris]

Multi-threaded processing would be nice .... though would entail some language extensions, could be a useful way to avoid firing phantoms in some situations & I would like to think enable thread synchronization & communications

On Friday, 25 October 2013 06:29:42 UTC+11, Eugene Perry wrote:

Now that Rocket is going to have the U2 products as well as D3, mvBase and mvEnterprise this might be an opportunity for some things to be put into the "D3" product.

 

[Kevin King]

That's a great idea Ross, but I doubt it would be of much interest unless Rocket can find a way to monetize it through license sales. Allowing multiple threads to run under a single license could be great for users, but not so great for Rocket's licensing income.

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Ross Ferris]

Yeah, I know .... it is just that there are some problems which would be easier to solve with a precision instrument, rather than a sledge hammer. Perhaps the additional licence revenue would come from additional sites ... though I'm not sure how many people would re-tool to take advantage, as this isn't "broken" so much as totally missing

[Symeon Breen]

Rocket allow upto 10 processes per client with device licencing, so as long as the threading fitted into this model I don’t think it would be a problem.

 

 

Interestingly at the first U2 university they showcased being able to call python classes directly from Unidata, and the python classes then did some multithreaded web work .  this never became part of the product tho.

[fwinans]

Conversely, some types of tools would be great to have for your own use,
but you'd never want to "share" them for various reasons like a) too hard to document,
b) easy to 'break' with all but the simplest usage situations, c) letting other people use
them would actually reduce my own profits

So you may find it worthwhile to build your own commands if you've got 'slow' time each
year, instead of taking long vacations then.

A few examples that I've idly considered in the past are;

   tool to recover files from a  raw tracks copy of a pick database that is too corrupt to
'boot up" any longer due to 'out of space' or severe cross-linked frames, etc.

  application program that does about the same thing as  sselect,
or as list -- so that you can add some odd special feature, or do some debugging that
kicks in for a particular file or account or text string in current item id, or 'prints' in a
very very strange meaning of that term

  application program that reads file-save tapes;  erm, that is not as insane as it sounds,
but the 'why' is a really long discussion, probably not very interesting either...

   application program that does boolean {bitwise}  operations on streams of bits given
as hex digits, like  OR or AND or Exclusive-OR  -- you can extend your D3 monitor with
these features, but that is waaay too much work to do on a client box out in the field
for just this small gain, so app. prog is the way to go, I say.

  applications to do, in basic, what several native os commands can do for you shelled out,
like diff or grep or  sed  or cut or md5sum or hexdump -- because you cannot always arrange to load
cygwin on a remote customer's d3/windows server and hey, these tools are really addicting for admin
use.

  command-line tool to replace an item's attribute with a constant or a copy of other attribute in same item.
{Normally only used in once-a-year  'clear the decks'  kind of operation, but vastly handy then!!!}

  application to do what search-system does.  I really hate search-system -- like the linux   sendmail
command,  it works really well, but is utterly useless to a casual user, since it has minimal docs and
a steep learning curve.  I don't think a hundred people use search-system in the whole united states.
I even have trouble understanding the source code to it. 
Makes me want to go out adn hire someone smarter, to take over my own job; aargh!

  some sort of 'thick client' that lets you log in to d3 on more than one window of your desktop and _actually_
_share_ _data_ from one window to the other non-interactively, like  run a prog in one session and emit the
error messages to the other session so they do not mess up your screen on the first session.  I've never used
perl, but maybe that would be one way to write this sort of thick client, instead of using accuterm or putty or
telnet.exe to log in to d3 server...  Maybe could even support extended character set, like standard ascii and a
dozen or so 'glyph' characters for punctuation and to help make @AM, @VM, @SVM more distinct in 
CT command output... {There goes my longing for the really nice APL character set, again!}  Or hey!  a thick
client that does graphics output.  I know Accuterm terminal emulator can display graphics from a linux accuplot
program output, but I couldn't even _begin_ to know how to display graphics from inside a basic program to an
accuterm screen, and if they ever drop this feature from future releases nobody would complain even a little,
so I'd hate to rely on it in my progs in any event.

[Ross Ferris]

Embedded

On Friday, 20 December 2013 00:05:14 UTC+11, fwinans wrote:

Conversely, some types of tools would be great to have for your own use,
but you'd never want to "share" them for various reasons like a) too hard to document,
b) easy to 'break' with all but the simplest usage situations, c) letting other people use
them would actually reduce my own profits

So you may find it worthwhile to build your own commands if you've got 'slow' time each
year, instead of taking long vacations then.

A few examples that I've idly considered in the past are;

   tool to recover files from a  raw tracks copy of a pick database that is too corrupt to
'boot up" any longer due to 'out of space' or severe cross-linked frames, etc.

or spend more time pro-actively managing system. I know many years ago I wrote a routine that monitored the printers in R83 (which I then ported to D3), that monitored the print queue so that WE could alert customers to the fact that their printers had run out of paper or were otherwise jammed "how did you know that ...". There really is little excuse for people running out of disk space these days, given the price/capacity of HDD's

  application program that does about the same thing as  sselect,
or as list -- so that you can add some odd special feature, or do some debugging that
kicks in for a particular file or account or text string in current item id, or 'prints' in a
very very strange meaning of that term

or add a reference to a CALLed dictionary item on the file, that way anything special for a particular file is localized there --> and as D3 will revert to looking for dictionary items on the MD if they can not be found in local file dictionary, can have a nice little ACCESS.DEBUG dictionary item you can add to any SEELECT statement, WITHOUT having to write your own SSELECT processor

  application program that reads file-save tapes;  erm, that is not as insane as it sounds,
but the 'why' is a really long discussion, probably not very interesting either...

I'm sure there is a good reason, but thankfully I've never stumbled up against it 

   application program that does boolean {bitwise}  operations on streams of bits given
as hex digits, like  OR or AND or Exclusive-OR  -- you can extend your D3 monitor with
these features, but that is waaay too much work to do on a client box out in the field
for just this small gain, so app. prog is the way to go, I say.

once more, I'd need to know WHY, but for performance this is something that should never be attempted in Basic (I see your reference to the Monitor, but don't know anway who can program for that), even if flashed, and with knowledge of the problem you are trying to solve, I'm guessing it would be far easier to leverage 3rd party products OUTSIDE OF D# that may provide this functionality, and operate at speeds many orders of magnitude higher. Horses for courses, and I've never had to use an XOR in a balance sheet yet! 

  applications to do, in basic, what several native os commands can do for you shelled out,
like diff or grep or  sed  or cut or md5sum or hexdump -- because you cannot always arrange to load
cygwin on a remote customer's d3/windows server and hey, these tools are really addicting for admin
use.

Simple solution ... don't use D3/Windows 'cause it isn't reliable 

  command-line tool to replace an item's attribute with a constant or a copy of other attribute in same item.
{Normally only used in once-a-year  'clear the decks'  kind of operation, but vastly handy then!!!}

I tend to use editor pre-store --> provided you don't mind the delay caused by the I/O load to the screen 

  application to do what search-system does.  I really hate search-system -- like the linux   sendmail
command,  it works really well, but is utterly useless to a casual user, since it has minimal docs and
a steep learning curve.  I don't think a hundred people use search-system in the whole united states.
I even have trouble understanding the source code to it. 
Makes me want to go out adn hire someone smarter, to take over my own job; aargh!

I believe there was a sys-admin recently that made the news by out-sourcing his day job to an Indian for 20% of his wage so he could relay for 100% of his time. What a great way to get new blood, and ideas !!

I don't understand why a casual user would want, or need, the ability to search an entire system, but treating SEARCH-SYSTEM as a black box that just works (like D3 itself), an hour or tow should give your casual user a better front end

  some sort of 'thick client' that lets you log in to d3 on more than one window of your desktop and _actually_
_share_ _data_ from one window to the other non-interactively, like  run a prog in one session and emit the
error messages to the other session so they do not mess up your screen on the first session.  I've never used
perl, but maybe that would be one way to write this sort of thick client, instead of using accuterm or putty or
telnet.exe to log in to d3 server...  Maybe could even support extended character set, like standard ascii and a
dozen or so 'glyph' characters for punctuation and to help make @AM, @VM, @SVM more distinct in 
CT command output... {There goes my longing for the really nice APL character set, again!}  Or hey!  a thick
client that does graphics output.  I know Accuterm terminal emulator can display graphics from a linux accuplot
program output, but I couldn't even _begin_ to know how to display graphics from inside a basic program to an
accuterm screen, and if they ever drop this feature from future releases nobody would complain even a little,
so I'd hate to rely on it in my progs in any event.

Depending on the type of errors, application or basic, for the former you can simply write out to a log file that can viewed by any number of other devices, and if the later, LIST-RUNTIME-ERRORS works well for me (surprising the number of people that don't know about this command). We have a variation to this theme in Visage so that we can received emails of any runtime errors generated at client sites so that we can be aware that something bad happened, and then fix the code [or data?] & distribute ASAP so that other people don't have similar problems). Shame you want a thick client though, 'cause with Visage it is a piece of cake to just drop a graph on a screen, and I can do a tad more with punctuation than a little smilie :-)

If you REALLY don't want your green screen to get mucked up, you could always try EXECUTE "my.buggy.program.or.proc" capturing LotsOfErrors and then write out to a file for reference

 

[fwinans]

Erm, I was hoping for some real-time feedback messages on what was happening with the target program;
maybe I should have called it 'debugging output' instead of 'error output'.  After I posted I realized that many
serial terminals have this feature of multiple scroll regions on the screen, so one could declare a really tall
screen and make the top 25 rows be for normal prog output, and the rows below that for 'reached milestone xxx'
type crt output.  Hopefully Accuterm supports one such emulation.    Oh and the linux prog is called gnuplot,
not accuplot.  Pity that few {none?} serial terminals have the push/pop cursor location like laserjet printers offer,
but D3   system(6) is meant to return current onscreen row number of cursor, I think...

Ross Ferris wrote:

  some sort of 'thick client' to emit the
error messages to another session s

[Scott Johnston]

[Scott Johnston]

Simple! Some DECENT debugger functionality!  DBL-CLK variable display and the ability to step backward!

[Jeremy Thomson]

Cursor editing of fields.

This should have been done in the '80s, its the 21st century already!

Ever tried do do terminal independant cusor key decoding, its a PITA

I worked on a site that had some clever D3 code to do cursor back, character insertion deletion etc.

Problem was this was a conversion of the D3 code in Universe, the result was that not even the backspace key worked.

Can you imagine how frustrating is was to the users to see a typo and not be able to even backspace to correct.

And please not some control character update type silliness, who wan't to learn control characters in the 21st century?

[Kevin Powick]

On Monday, 30 December 2013 17:00:38 UTC-5, Jeremy Thomson wrote:

who wan't to learn control characters in the 21st century?

Complaints about moving into the 21st century from users of character/terminal interfaces.  Irony lives here.

--

Kevin Powick

[Ross Ferris]

I thought everyone already wrote their field edit routines IN the 1980's already ... back/forward characters/words/fields, insert/delete/backspace, searching etc etc etc, and as Kevin said you should replace "terminal indepedent" with "browser independent" (where you can also access other "freebies", like integrated spell checking) ... if you are looking for a solution for either platform, we can help :-)

HAPPY NEW YEAR to all !!!

[Jeremy Thomson]

There are places were the screen drivers are still hard coded for the Viewpoint ternminal type. Why change when you can just sell the clients AccuTerm?

[Ross Ferris]

I think a similar argument was made for the wooden, spoked wheel - still very popular with the Amish (who arguably have a better lifestyle than most of us!)

I would suggest that the fact that your application does contain hard coded references like this for a device that shouldn't have been sold this century, whilst possibly a testament to the core application, may also indicate that the users may be starved of modern/current functionality, and as such, unless some application renovation is undertaken (and assuming they are still competitive in their market), may be ripe for migration AWAY from "pick", OR (hopefully) to a more current multi-value application.

Of course, I believe that Visage is the best tool for such an evolution as Visage screens will happily run alongside their green screen cohorts, but unless you start to do something in this regard for your client/employer, I would suggest that they will all too quickly become one of the many companies that "used to run multi-value" :-(

[Peter McMurray]

I would like to see a couple of minor changes to the Access verbs SORT and LIST, say SORTU and LISTU.

The only variation to the standard verbs is that the new verbs calculate character space using UNICODE UTF8.

I wrote a complete data edit routine for UTF8 input that works beautifully as Pick is a character based storage mechanism and UTF8 does not involve any of the standard Pick delimiters.  A simple check of the value of the first character tells one immediately whether it is an ASCII character or involves more than one of the character group. My data entry is displayed perfectly in vertical format and only needs this minor variation to do columnar output.

One only needs to follow a couple of simple rules like JSON and all is complete for all the Unicode planes with no changes to standard Pick storage.

All arithmetic is done using the characters 0....9 frequently called Arabic although they are in fact Hindu and yes genuine Arabic car number plates use 0...9 beside the genuine Arabic equivalent so it is not a problem.  Chinese in its several variations has words for numbers just as we do e.g. we say/write twenty but we calculate with 20.

I am bemused as to how Jeremy Thomson imagines a data entry routine that does data edit of control characters without using control characters.  Maybe he belongs to that group of programmers that wrecked the Universe INPUT @ command by putting in control characters to change the display.  As always a little knowledge is a dangerous thing - I have used protected screens for 35 years and that piece of stupidity wrecked the screen.

[Jeremy Thomson]

On Wednesday, January 8, 2014 10:33:38 AM UTC+13, Peter McMurray wrote:

I am bemused as to how Jeremy Thomson imagines a data entry routine that does data edit of control characters without using control characters.  Maybe he belongs to that group of programmers that wrecked the Universe INPUT @ command by putting in control characters to change the display.  As always a little knowledge is a dangerous thing - I have used protected screens for 35 years and that piece of stupidity wrecked the screen.

Perhaps I should have said control character sequences instead of using the cursor key sequences the terminal emulators generate.

In particular the update editor that I always tried not to use because of its arcane control character sequences.

Pick is pre-SQL, pre-UNIX and pre-VDU.

That it was designed for teletype style interface is apparent in that there has never been in OS managed way of supporting the cursor keys.

[Ross Ferris]

Jeremy,

As you are talking D3, please be aware that it IS possible to have your system configured for use with the UPdate processor so that the cursor keys work on a "dumb terminal" (or using something like the AccuTerm emulator) 

However, to REALLY solve your "problem" you need to move away from the 20th Century and the terminal emulator and embrace everything the 21st Century has to offer ... and support or cursor movement keys for data input is just the beginning (and as noted previously, MANY D3 applications/tools also offer[ed] this capability for green screen environments as well.

As you say, the MV data model pre-dates SQL, but this doesn't mean that people HAVE to limit their MV solutions to using the technology available from that epoch. For example, I have been able to enter data into my MV application using speech recognition for over a decade, and I was using a mouse with my green screen application a decade before that.

It will be 20 years this year since we started the project that eventually morphed into the web application development framework that today we know as Visage. The initial scope of the project was to produce a terminal emulator that would allow us to add GUI elements to our screen. When this failed with Visual Basic (anyone remember how many floppies were in the install besides me?), we migrated the Project to Delphi 2 (where we actually got something working), shortly before we got wind of what was in the pipeline for HTML & IE4.

The rest, as they say, is history .... and yet we still have people arguing the arguing the toss about the use of cursor keys for data input!?!?

C'MON GUYS!!!

It is SOOOO EASY to join the party! If you are interested, drop me an email & I can give you a quick tour of the things you can do with your existing code, database structure and a tool like Visage, and it will even "place nice" with your existing applications, so you don't have to do everything all at once.

[Kevin Powick]

On Sunday, 12 January 2014 07:59:08 UTC-5, Ross Ferris wrote:

 

If you are interested, drop me an email & I can give you a quick tour of the things you can do with your existing code, database structure and a tool like Visage, and it will even "place nice" with your existing applications, so you don't have to do everything all at once.

Having recently been walked through a Visage demo by Ross, I must say that I am thoroughly impressed.  For MV users looking for a complete development solution with MV at its heart, Visage should be taken very seriously.  

--

Kevin Powick 

[Peter McMurray]

Hi Jeremy

There is no OS managed way of using control characters as every keyboard generates a scan code that is then interpreted to a virtual key code that depends on what you are using.  It has nothing to do with when a system such as Pick was designed.

We at Excalibur were the first to develop formatted screens for Pick.  My partner, Stuart Evans, wrote a screen generator for the AWA VTE6 in which we used foreground and background cursors , multi pages, you name it.  We were criticised for not using scrolling teletype at the time - funny how the world has changed.  Microsoft are the best at standardising http://msdn.microsoft.com/en-us/library/windows/desktop/gg153546(v=vs.85).aspx however all systems are dependent on screen emulations in some manner.

At the same time I have never embedded one screen type exclusively in a system.  In my opinion one should have that sort of information in an INCLUDE that is activated by user. I hate to think how many options I have allowed for over the years in this way - VTE6, AMD, a weird Canadian piece of junk, Wyse etc. through a number of terminal emulators ranging from the excellent LykeWyse to Accuterm and Anzio. Funnily enough I never did the boat anchor that came with the first Realities called a Prism I believe.

Currently I use Anzio for UTF8 and PrintWizard plus Accuterm.  I simply set them to Wyse with an answerback and then I can use the emulation actions to do things like display a PDF from the server on the operator's machine.  I have full editing for the complete UTF8 set of Unicode in all planes and I am not dependent on which version of Pick Multivalue system I am using.  However I do have to be wary of silly things like the Univers Input@ which hopefully has been dumped.

On Wednesday, January 8, 2014 10:33:38 AM UTC+13, Peter McMurray wrote:

I am bemused as to how Jeremy Thomson imagines a data entry routine that does data edit of control characters without using control characters.  Maybe he belongs to that group of programmers that wrecked the Universe INPUT @ command by putting in control characters to change the display.  As always a little knowledge is a dangerous thing - I have used protected screens for 35 years and that piece of stupidity wrecked the screen.

[Charlie Noah]

Hi Peter,

Just curious, when did Excalibur develop formatted screens for Pick?

Thanks,
Charlie

Tiny Bear Wild Bird Store
Home of "Safety Net Shipping"
http://www.TinyBearWildBirdStore.com
Toll Free: 1-855-TinyBear (855-846-9232)

[Brian Speirs]

How about something useful ...

For example, how about allowing each of the Rocket databases to have native access to the filesystems of the other databases. Therefore, if you are on D3 and want to access a UV file (or vice-versa), you could simply OPEN it, and READ the items. The database would need to assess what format the file was in, and then use the appropriate database engine for the file handling. To speed things up, it would probably need to maintain a table of what format each file was in.

Similarly, we could have a CONVERTDB utility which would read your D3 files and convert them to UV/UD/mvBASE files (or any other direction).

Cheers,

Brian

[Ross Ferris]

I would think there may be far too few people/paying customers to come close to any cost/benefit analysis being positive in that respect. Having said that, I suppose you could also view this as a subset of the possibilities that COULD become available if the innards of OSFI were made public, as suggested earlier in this thread by TonyG. Of course, if you REALLY wanted/needed to do this, then using OpenDB from D3, and setting up SQL interfaces on the UD/UV side of the equation should deliver a workable solution TODAY.

Not free, but perhaps highlighting the fact there are a lot of latent capabilities within D3 that most people don't try & harness.

As to the CONVERTDB idea, raw data is easy .... it is when you come into the bowels of things like dictionaries that stuff can get unstuck. The example I always fall back to was a client that INSISTED they wanted/needed to run on UD. Loved our app & Unidata Australasia were engaged to port our app from "Advanced Pick" to "Unidata". To cut a long story short, we had some "interesting" dictionaries at the time, and the quoted time (thankfully at fixed price" for conversion went frm 2 weeks, to a month, 3 months and ultimately a year ... needless to say we lost the deal, but interestingly on the basis that they turf UD and migrate to jBase.

Which of course explains one of the classic errors we have made over the years .... we listen to customers :-)

[Peter McMurray]

Hi Charlie

Excalibur was registered as a company about September 1977.  However our partner, Stuart Evans, wrote the formatted screen programs in late 1976 early 1977 - I think he called it ScreenGen at that time. He released it to Peter Harvey around March 1977 and we used it to write Pobol, the first Pick 4GL I believe although we called them system generators then. which we released about the time Excalibur was registered.

However Stuart had a particularly scary and brilliant idea - if Pobol is so good we should write it in itself.  So goodbye to an 18" pile of printouts to be replaced by a set of parameters.  This meant that the first formal release of formatted screens to AWA was late 1977 via Pobol  which I then used to develop major systems for Gardner & Lang Real Estate and Maxarts Manufacturing and we sold it to ASEA as I could not do all the systems myself.

Believe me formatted event driven screens caused quite a discussion when the official documents from AWA under Dick Pick's direction said that screens should act in teletype mode.  Thus all those ghastly programs with INPUT this , INPUT that then oops an error do it all again.

In fact when I demonstrated a screen with 42 fields on it to an English IT expert about 1980 and happily went from the control line to say field 37 to make a change: he was blown away and reminded me the accepted wisdom was teletype or at best an IBM formatted screen with a Commit Function and re-enter everything if the commit found an error.

Hi Peter,

Just curious, when did Excalibur develop formatted screens for Pick?

Thanks,
Charlie

[Charlie Noah]

Thanks for all the great info, Peter. I seem to remember working with ScreenGen way, way back when. This is the kind of information I'm sure Dawn Wolthuis would love to put in her MV history files.

Charlie

--

[fwinans]

D3 really, really, needs a command to seek out GFE's in the free pool -- how many times over the years have I logged in
just to get a 'frame out of range'  error, but then had the slippery gfe-bearing frame get 'lost' again just because it did not
happen to be employed as part of any file at the time I do a dummy save to detect it?   So, some new verb of D3
akin to the  linux  fsck  or to the windows CHKDSK  command is a really good plan.

If you say 'Oh, but we never get GFEs anymore, ever!  D3 is perfect, now'  Well, I just won't believe that --D3 is too intricate for that, even at a glance.  And if D3 should ever run fully out of unstomped bugs, then Windows or Linux will gladly mutate a bit in their next release to resupply it with many many more.

[Ross Ferris]

Nice idea, but wouldn't hold your breath. Only time I've seen GFE's in the last decade or so with current versions of D3/Linux is following a power failure - D3/Windows, WELL, my views are well known on that product (which is a shame).

I'd actually extend the idea a tad and include DEFRAG capabilities, to avoid the need for a full backup/restore cycle. 

[Walter Kiess]

I only just found this post today. For what it's worth, I'd like to see Rocket do something about the need to LOGOFF then log on again into the same account when making changes to a file's DICT item attrib 15 & 16 which describes the input & output macros. It should just take effect immediately.