A possible alternative solution just struck me. Perhaps, after an abnormal
system outage and before users are allowed on the system, you could run a
program to examine the database(s) where this sequential number is stored,
determine the highest value, and then update your *USRSPC values
appropriately. A little code, but you would not have to change your
existing code...

Bruce

On Sat, Dec 6, 2014 at 8:29 AM, Bruce Vining <bvining@xxxxxxxxxxxxxxx>
wrote:

As Chuck suggested earlier, a journaled *DATARA approach might be the
wiser approach. Use of a *USRSPC, with pointer access, for maintenance of
the "next sequential" number might be fast and expedient, but as pointed
out earlier doesn't necessarily mean the "next sequential" number is
written to auxiliary storage for retention across unplanned system outages.
A *DTAARA, for instance, is what the system uses when creating a SQL
Sequence (which, if you're not familiar with them, provides a "next
sequential" number capability).

As anyone who knows me knows, I use pointers and *USRSPCs a lot. But I
would not use them as you are doing in a case where I need to retain
changed values across unplanned system outages. If you do want to continue
using the *USRSPC approach then Chuck's pointer to Set Access State
(SETACST) would be worth looking at. Personally I would use a *DTAARA.

Bruce Vining




On Fri, Dec 5, 2014 at 12:32 PM, Evan Harris <auctionitis@xxxxxxxxx>
wrote:

Hi Rob

You do realize that that pointer addition function would also have to
change to use the new additional function in your example don't you ? :)

That said, I 100% agree that using pointers is a much easier and IMO ends
up with clearer code.

On Sat, Dec 6, 2014 at 1:08 AM, <rob@xxxxxxxxx> wrote:

I SO much prefer using the pointer method! Once you get past thinking
pointers are some sort of tool of the devil it is so much easier.

For example, let's say IBM announced the rNext of the OS would no longer
support simple addition in RPG. Any new compiles would have to replace
x=y+z;
with
x=PerformAddition(y : z : '1' : ErrCde);
where the third parameter was whether or not to allow truncation if the
sum of y + z was greater than the size of x, and the fourth parameter
was
the standard error code.
Wouldn't that be nuts?
Then why would anyone prefer calling QUSCHGUS over
myChar char(10) based(pmyChar);
...
for x = 1 to ListNumber;
pmyChar=Initial + (OffsetSize * x);
dsply myChar;
EndFor;


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Monnier, Gary" <Gary.Monnier@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 12/04/2014 04:05 PM
Subject: RE: User Space question
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Look at QUSCHGUS's parameter 5 - Force changes to auxiliary storage


Force changes to auxiliary storage
INPUT; CHAR(1)
The method of forcing changes made to the user space to auxiliary
storage.
The valid values are as follows:
0

Does not force changes. Normal system management writes the changes to
auxiliary storage.

1

Forces changes asynchronously. This interrupts the normal system
management and ensures that the user space is written to auxiliary
storage.

2

Forces changes synchronously. This interrupts the normal system
management
and ensures that the user space is written immediately to auxiliary
storage.




Or use a pointer to the space (QUSPTRUS api). Obtaining a pointer to
the
user space will provide virtually immediate update when the value for
the
space is changed.





-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Michael Smith
Sent: Thursday, December 04, 2014 12:39 PM
To: Midrange Systems Technical Discussion
Subject: User Space question



This past week our UPS failed, as a result the building lost power and
the
iSeries (720 , with V7R1) immediately shutdown.



The only "fall out" has been related to several user spaces that we use
as
"next sequential" number counters.



The value of the user spaces when the system came back up did not
reflect
updates that had occurred during the day, and as a result various files
had duplicate "sequential" numbers.



My question, is there a function for a user space that is similar to
FRCRATIO for a database file?



TIA

Michael Smith





--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx<
mailto:MIDRANGE-L@xxxxxxxxxxxx> To subscribe, unsubscribe, or change
list
options,

visit: http://lists.midrange.com/mailman/listinfo/midrange-l

or email: MIDRANGE-L-request@xxxxxxxxxxxx<
mailto:MIDRANGE-L-request@xxxxxxxxxxxx> Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l
.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




--

Regards
Evan Harris
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




--
Regards,
Bruce
www.brucevining.com
www.powercl.com





This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].