|
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 thinkingwas
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
the standard error code.storage.
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
The valid values are as follows:management
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
and ensures that the user space is written immediately to auxiliarythe
storage.
Or use a pointer to the space (QUSPTRUS api). Obtaining a pointer to
user space will provide virtually immediate update when the value forthe
space is changed.the
-----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
iSeries (720 , with V7R1) immediately shutdown.as
The only "fall out" has been related to several user spaces that we use
"next sequential" number counters.reflect
The value of the user spaces when the system came back up did not
updates that had occurred during the day, and as a result various fileslist
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
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
list
--
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
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.