Re: Add fields to physical file without exclusive lock _ formerly Re: Stupid question of the century

Thanks for your reply steelville
I have often pondered the idea of placing the io of file(s) into an
external program/service program, but unless I am mistaken, this would
STILL not alleviate the initial situation of having to force the users off
the system while the file is being changed.


Alan Shore
Programmer/Analyst, Distribution
E:AShore@xxxxxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

midrange-l-bounces@xxxxxxxxxxxx wrote on 05/10/2009 10:56:38 PM:

The boss's boss wants a quicker turnaround of projects, so much so that

we

have been asked to look into other languages available on the AS/400

(EGL

is the first one and that might mean another thread in and of itself)
He is tired of having to wait to change/recompile ALL the applicable
programs for a change to a file, then having to push the appropriate

people

off the system so that these changes can be applied to the files

on the production system
----
A laudable motivation on his part for the project.

FYI and FWIW, sometimes I've considered what it would be like to have
externalized data access, like this. It could be done

==>One. Define the file itself first, and/or appropriate logicals.

==>Two. Write a service program with a global externally defined data
structure for reading the file into said data structure and/or writing
to the file from it.

==>Three. Procedures that receive parameters representing key values to
access these files using said externally described data structure(s).
This can be done with either RLA using RPG I/O opcodes or with SQL
statements, take your pick. %Parms can be used in this connection for
partial keys... To read, say:

Data1DS = File1( Key1: Key2: Key3: ) ---]

More subprocedures that simply return the current value for a given

field:

P Field1 PR
D Field1 DS n
D Value 10a
/free
Value = Data1DS.Field1
Return Value
/end-free

==>Four.Use this approach --using calls to the service program
subprocedures-- in the programs that use the data from that file. Every
time.

==>Five. When you need to add a field to this format, the only thing you
have to change is the service program and recompile to use that file. If
you have library lists set up properly, I believe you can implement the
changed service program into production dynamically while other programs
that use it are running, as they are bound upon activation.

==>Six. This would require some consistent shop discipline and maybe
change management checks before promoting programs to production, but I
think it's doable. Situations like you describe are precisely why many
of us have considered this approach of externalizing data access this
way. I speculate that the main reason it isn't implemented more in shops
is just momentum.

--aec

--
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.