Re: Protect subfile records when maintaining control record

Sorry, not sure I understand. I've not seen the keyword DSPCTL before?
And surely if I set SFLDSPCTL to *OFF I won't be able to update any figures
on the control record?


On Tue, 16 Dec 2025 at 23:22, Infodorado InfoDorado via RPG400-L <
[email protected]> wrote:

> Yes, PROTECT would be one way but would require setting the indicator on
> the PROTECT to default to NOT(PROTECT) and updating all the subfile
> records.
> But you can use the DSPCTL and SFLDSPCTL keywords. To change just the
> control record, set the indicators and redisplay the same SFLCTL record but
> SETOF the indicator(s) for SFLDSPCTL.
>
> --Alan Cassidy
>
>
> > On 12/15/2025 8:50 AM EST Patrik Schindler <[email protected]> wrote:
> >
> >
> > Helo Liam,
> >
> > Am 15.12.2025 um 13:16 schrieb liam henderson <[email protected]
> >:
> >
> > > Hi,
> > > We have a subfile with maintainable entries, and the control record
> also
> > > has maintainable entries, but is locked down.
> > > On function key press we allow maintenance of the control record
> > > I was trying to find an easy way to lock down the subfile entries on
> > > display without having to read through the subfile setting a protect
> > > indicator for each record/field
> >
> > As far as I know, each SFL row is in fact a separate record entity with
> its own complete set of indicators and flags. I think you cannot globally
> protect the contents of an SFL as intended.
> >
> > > I looked at other code we have that does this, and it seems they
> create an
> > > exact copy of the control format and display that using PROTECT
> keyword,
> > > but thought there might be an easier way. Also means maintaining two
> > > versions of the same screen format.
> >
> > Had a look about the PROTECT keyword.
> >
> > "Option indicators are valid for this keyword."
> >
> > Maybe this is a way to get rid of duplicate maintenance?
> >
> > :wq! PoC
> >
> >
> > --
> > This is the RPG programming on IBM i (RPG400-L) mailing list
> > To post a message email: [email protected]
> > To subscribe, unsubscribe, or change list options,
> > visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
> > or email: RPG400-L-request-+hD5IHI5Xscn3HwCXmMcX9BPR1lH4CV8@public.gmane.org
> > Before posting, please take a moment to review the archives
> > at https://archive.midrange.com/rpg400-l.
> >
> > Please contact support-FMtJrHiV//lnDLsaKlm4mFaTQe2KTcn/@public.gmane.org for any subscription
> related questions.
> --
> This is the RPG programming on IBM i (RPG400-L) mailing list
> To post a message email: [email protected]
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request-+hD5IHI5Xscn3HwCXmMcX9BPR1lH4CV8@public.gmane.org
> Before posting, please take a moment to review the archives
> at https://archive.midrange.com/rpg400-l.
>
> Please contact support-FMtJrHiV//lnDLsaKlm4mFaTQe2KTcn/@public.gmane.org for any subscription related
> questions.
>
>
-- 
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: [email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request-+hD5IHI5Xscn3HwCXmMcX9BPR1lH4CV8@public.gmane.org
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support-FMtJrHiV//lnDLsaKlm4mFaTQe2KTcn/@public.gmane.org for any subscription related questions.