Unidata to Universe differences

Hi - I am switching back from 20 years of Unidata, to Universe....can't remember all the differences but I'm sure I will pick it back up quickly. One thing I just tried and couldn't do...editing mv and smv lines with the EV (edit values) command.... can someone pop off the command to edit values in the line editor on Universe?

Thanks!

------------------------------
Kathleen Hambrick
Programmer at Colwell
------------------------------

You should find AE also exists in UniVerse, so you can still use that.

------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------

Yes, of course, there are other editors, but I was specifically looking at line editor to line editor differences. This company uses Accuterm so there are a bunch of editors I will use. Just looking to start off with what I know best....basic line editor.

------------------------------
Kathleen Hambrick
Programmer at Colwell
------------------------------

In Universe, use the ED editor, then at the editor prompt, type in ^ to go into "Up Arrow mode". This will show VMs and SVMs by ASCII number.

Brian

Thanks Brian - I guess I need my answer from someone who has used both.

The up arrow mode does of course display mv, smv, and all other control characters but that is not what I am asking. In Unidata, there is a command named EV which allows you to edit your multi, and then sub, values in a sort of subordinate line editor. If you ever see it you'll go 'oh, cool'.

I was hoping there was an equivalent. Sounds like there isn't, which is fine. Thank you for your response.

------------------------------
Kathleen Hambrick
Programmer at Colwell
------------------------------

We, at U2logic, write for both Universe and Unidata. The biggest difference is the native LOCATE function in the Universe database. If you use the INFORMATION version like we do when UniBasic Universe then $BASICTYPE "U" the default basic type in Unidata there will be no problem. However, if you don't all of your locates may be suspect.

The other big deal is indexing. Universe 12.1 does not allow you to change indexes while in use which is now a big problem for our UniBasic Universe code that created indexes. This is not an issue in Unidata. We believe the next version of Universe will fix these issues we have lived with for several years.

The @LOGNAME variable works in Unidata but not in Universe. We use this code for both: USER = @LOGNAME ; IF INDEX(USER,"\\",1) THEN USER = FIELD(USER,"\\",2)

The SYSTEM variables are not the same between the databases. For example IP.ADDRESS = SYSTEM(42) in Universe is IP.ADDRESS = SYSTEM(512) in Unidata.

After a SELECT list, you might have this code in Universe MAX.VALUES = @SELECTED which will need to be MAX.VALUES = @SYSTEM.RETURN.CODE in Unidata.

That is all I can think of off the top of my head.

------------------------------
Doug Averch
Owner
U2 Logic
www.u2logic.com/tools.html
------------------------------

Thanks Brian - I guess I need my answer from someone who has used both.

The up arrow mode does of course display mv, smv, and all other control characters but that is not what I am asking. In Unidata, there is a command named EV which allows you to edit your multi, and then sub, values in a sort of subordinate line editor. If you ever see it you'll go 'oh, cool'.

I was hoping there was an equivalent. Sounds like there isn't, which is fine. Thank you for your response.

------------------------------
Kathleen Hambrick
Programmer at Colwell
------------------------------

EV is not a UniData Command.

------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------

EV must be something added by one of your terminal emulators or a utility that someone has written it does not exist in UniData as a standard command.

------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------

AE in both UniVerse and UniData will allow you to use ^ to enter control characters or display them.

:AE CUSTOMER 1
Top of "1" in "CUSTOMER", 10 lines, 94 characters.
*--: P
001: Smith, Harry
002: 1414 W. 8th
003: Boulder
004: CO
005: 80302
006: 3032324987
007: V2001ýV5004ýV8181
008: 9611ý9610ý9611
009: HýDýM
010: 22
Bottom.
*--: ^
Unprintable characters shown.
*--: P
Top.
001: Smith, Harry
002: 1414 W. 8th
003: Boulder
004: CO
005: 80302
006: 3032324987
007: V2001^253V5004^253V8181
008: 9611^2539610^2539611
009: H^253D^253M
010: 22
Bottom.
*--:

------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------

EV must be something added by one of your terminal emulators or a utility that someone has written it does not exist in UniData as a standard command.

------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------

Hi Jonathon, Its absolutely possible that EV was added by someone but I would have no way of knowing that, or by whom. There are only a few differences I have found within the basic line editor between Unidata and Universe but this was an obvious one. Not sure how to add or delete line editor commands so I wouldn't know how to find it even if i was on my last jobs site, which I am not.

Our terminal emulator was wintegrate, but as that is a rocket product I assume it wasn't from them either or you would know what I am babbling on about.

No, it was not a keyword command, it was within the line editor commands themselves, like 'p' to page lines. But you are a rocket support guy so I will take your word for it.

That's too bad because it was very cool :)

------------------------------
Kathleen Hambrick
Programmer at Colwell
------------------------------

EV must be something added by one of your terminal emulators or a utility that someone has written it does not exist in UniData as a standard command.

------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------

I assumed it was delivered unidata functionality, as well.

Makes me wonder if this is an extension of some sort added by Datatel/Ellucian. Here's an example of how it works:

The list can now be navigated/edited as if they were attributes. Then enter Q/FI when done.

'EV' is used for value marks, and 'SV' is for sub-value marks.

------------------------------
Shawn Waldie
enterprise application developer
Rocket Forum Shared Account
Los Angeles CA US
------------------------------

I assumed it was delivered unidata functionality, as well.

Makes me wonder if this is an extension of some sort added by Datatel/Ellucian. Here's an example of how it works:

The list can now be navigated/edited as if they were attributes. Then enter Q/FI when done.

'EV' is used for value marks, and 'SV' is for sub-value marks.

------------------------------
Shawn Waldie
enterprise application developer
Rocket Forum Shared Account
Los Angeles CA US
------------------------------

Good Catch Shawn, I didn't check to see EV was a command within AE. it does look useful.

------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------

I assumed it was delivered unidata functionality, as well.

Makes me wonder if this is an extension of some sort added by Datatel/Ellucian. Here's an example of how it works:

The list can now be navigated/edited as if they were attributes. Then enter Q/FI when done.

'EV' is used for value marks, and 'SV' is for sub-value marks.

------------------------------
Shawn Waldie
enterprise application developer
Rocket Forum Shared Account
Los Angeles CA US
------------------------------

:AE CUSTOMER 1
Top of "1" in "CUSTOMER", 3 lines, 17 characters.
*--: HELP EV

Concept: value.edits (ve)

Commands: ListValues (LV), KeepValues (KV), ListKeptValues (LKV),
InsertValue (IV), ReplaceValue (RV), DeleteValue (DV),
EditValues (EV), EditSubValues (ESV), ChangetoValues (CV),
ChangetoWords (CW)

ListValues: lists values on current line, using value-mark as delimiter.
KeepValues: keeps values on current line in special @values, @kv1-@kv999.
ListKeptValues: lists contents of @words or reports that KeepValues has
not been used yet.
InsertValue: places a value before other values in the line, using a
number; can insert subvalues also.
ReplaceValue: replaces a value with another value; can replace
subvalues also.
DeleteValue: deletes a value; can delete subvalues also.

------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------

I assumed it was delivered unidata functionality, as well.

Makes me wonder if this is an extension of some sort added by Datatel/Ellucian. Here's an example of how it works:

The list can now be navigated/edited as if they were attributes. Then enter Q/FI when done.

'EV' is used for value marks, and 'SV' is for sub-value marks.

------------------------------
Shawn Waldie
enterprise application developer
Rocket Forum Shared Account
Los Angeles CA US
------------------------------

Shawn - THANK YOU!! yes!

I do remember now that we had the AE guts in the ED keyword... so I will use AE instead of ED here! Thank you for knowing what I was talking about! :)

------------------------------
Kathleen Hambrick
Programmer at Colwell
------------------------------

Hi - I am switching back from 20 years of Unidata, to Universe....can't remember all the differences but I'm sure I will pick it back up quickly. One thing I just tried and couldn't do...editing mv and smv lines with the EV (edit values) command.... can someone pop off the command to edit values in the line editor on Universe?

Thanks!

------------------------------
Kathleen Hambrick
Programmer at Colwell
------------------------------

Hi

If your dict are correctly defined you can have a look to REVISE verb. It allow to edit by value of field.

I hope this help.

------------------------------
Manu Fernandes
------------------------------

We, at U2logic, write for both Universe and Unidata. The biggest difference is the native LOCATE function in the Universe database. If you use the INFORMATION version like we do when UniBasic Universe then $BASICTYPE "U" the default basic type in Unidata there will be no problem. However, if you don't all of your locates may be suspect.

The other big deal is indexing. Universe 12.1 does not allow you to change indexes while in use which is now a big problem for our UniBasic Universe code that created indexes. This is not an issue in Unidata. We believe the next version of Universe will fix these issues we have lived with for several years.

The @LOGNAME variable works in Unidata but not in Universe. We use this code for both: USER = @LOGNAME ; IF INDEX(USER,"\\",1) THEN USER = FIELD(USER,"\\",2)

The SYSTEM variables are not the same between the databases. For example IP.ADDRESS = SYSTEM(42) in Universe is IP.ADDRESS = SYSTEM(512) in Unidata.

After a SELECT list, you might have this code in Universe MAX.VALUES = @SELECTED which will need to be MAX.VALUES = @SYSTEM.RETURN.CODE in Unidata.

That is all I can think of off the top of my head.

------------------------------
Doug Averch
Owner
U2 Logic
www.u2logic.com/tools.html
------------------------------

Thank you Doug - that is very helpful! :)

Glad to be helpful. I posted this 2 days ago. Not sure what the problem what the delay was.

------------------------------
Doug Averch
Owner
U2 Logic
www.u2logic.com/tools.html
------------------------------

We, at U2logic, write for both Universe and Unidata. The biggest difference is the native LOCATE function in the Universe database. If you use the INFORMATION version like we do when UniBasic Universe then $BASICTYPE "U" the default basic type in Unidata there will be no problem. However, if you don't all of your locates may be suspect.

The other big deal is indexing. Universe 12.1 does not allow you to change indexes while in use which is now a big problem for our UniBasic Universe code that created indexes. This is not an issue in Unidata. We believe the next version of Universe will fix these issues we have lived with for several years.

The @LOGNAME variable works in Unidata but not in Universe. We use this code for both: USER = @LOGNAME ; IF INDEX(USER,"\\",1) THEN USER = FIELD(USER,"\\",2)

The SYSTEM variables are not the same between the databases. For example IP.ADDRESS = SYSTEM(42) in Universe is IP.ADDRESS = SYSTEM(512) in Unidata.

After a SELECT list, you might have this code in Universe MAX.VALUES = @SELECTED which will need to be MAX.VALUES = @SYSTEM.RETURN.CODE in Unidata.

That is all I can think of off the top of my head.

------------------------------
Doug Averch
Owner
U2 Logic
www.u2logic.com/tools.html
------------------------------

That's a great list!

One other thing that used to be a problem (at least for me!) is appending null values to a multivalued list. Not sure if this is still a difference, but always used to get me when moving code over to Universe.

LIST='A'
LIST<1,-1>=''
LIST<1,-1>='C'
CRT LIST

In Unidata this prints A}}C. Not sure if this difference still exists, but I still tend to do POS=DCOUNT(LIST<1>,@VM)+1 and then use an explicit variable when trying to update multiple dynamic arrays.

------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------

Good to know! I will keep my eye open for that one! Thanks

That's a great list!

One other thing that used to be a problem (at least for me!) is appending null values to a multivalued list. Not sure if this is still a difference, but always used to get me when moving code over to Universe.

LIST='A'
LIST<1,-1>=''
LIST<1,-1>='C'
CRT LIST

In Unidata this prints A}}C. Not sure if this difference still exists, but I still tend to do POS=DCOUNT(LIST<1>,@VM)+1 and then use an explicit variable when trying to update multiple dynamic arrays.

------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------

Just an additional note here (Unidata 8.2), that actually sped up some of our long running processes.
We have variables that might have a few hundred thousand multi-values. Rather than use the <1,-1> methodology,
we append the variable with an @VM and the data element. This seems to eliminate the need to traverse the entire string before appending the data. I would imagine it would work in UniVerse as well.
LIST = LIST: @VM : "C" or LIST := @VM :"C"

------------------------------
David Hanson
Senior Software Engineer
basys Inc
Baltimore MD US
------------------------------

Thank you Doug - that is very helpful! :)

I did a conversion UV to UD many years ago, and IIRC, biggest problem was format of VOC entries.

------------------------------
Kate Stanton
Software Developer
Walstan Systems
AUCKLAND NZ
------------------------------

Just an additional note here (Unidata 8.2), that actually sped up some of our long running processes.
We have variables that might have a few hundred thousand multi-values. Rather than use the <1,-1> methodology,
we append the variable with an @VM and the data element. This seems to eliminate the need to traverse the entire string before appending the data. I would imagine it would work in UniVerse as well.
LIST = LIST: @VM : "C" or LIST := @VM :"C"

------------------------------
David Hanson
Senior Software Engineer
basys Inc
Baltimore MD US
------------------------------

It does. Use that all the time.

------------------------------
Harry Hambrick
Senior Software Developer
Rooms To Go Inc
Seffner FL US
------------------------------

Just an additional note here (Unidata 8.2), that actually sped up some of our long running processes.
We have variables that might have a few hundred thousand multi-values. Rather than use the <1,-1> methodology,
we append the variable with an @VM and the data element. This seems to eliminate the need to traverse the entire string before appending the data. I would imagine it would work in UniVerse as well.
LIST = LIST: @VM : "C" or LIST := @VM :"C"

------------------------------
David Hanson
Senior Software Engineer
basys Inc
Baltimore MD US
------------------------------

Ah, that's a really good reminder!

I don't often produce lists with hundreds of thousands of entries, but when consuming them the opposite trick to the :@VM is to use REMOVE -

LOOP
REMOVE NEXT.VAL FROM HUGE.LIST SETTING MORE

UNTIL NOT(MORE) DO
  * Do something with NEXT.VAL

REPEAT

Is much faster than traversing the list. I think that works in both U2's - might even go back to the original PICK days..

------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------

Ah, that's a really good reminder!

I don't often produce lists with hundreds of thousands of entries, but when consuming them the opposite trick to the :@VM is to use REMOVE -

LOOP
REMOVE NEXT.VAL FROM HUGE.LIST SETTING MORE

UNTIL NOT(MORE) DO
  * Do something with NEXT.VAL

REPEAT

Is much faster than traversing the list. I think that works in both U2's - might even go back to the original PICK days..

------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------

I did use the REMOVE in Unidata and it really sped up accessing large arrays. It seems to be different in Universe but I haven't had a need to try it yet.

------------------------------
Harry Hambrick
Senior Software Developer
Rooms To Go Inc
Seffner FL US
------------------------------

Sign up

Please log in or register:

Welcome to the Rocket Forum!

Please log in or register:

Scanning file for viruses.

This file cannot be downloaded