Re: Unattended backup -- MIDRANGE-L

One other issue has come to mind. Maybe it isn't an issue. Tape head
cleaning. Should tape head cleaning be a planned activity? How to
determine the appropriate time interval between cleanings? What does 3590
do when it determines that heads need to be cleaned? Anything that the OS
can detect?

My ancient experience with B50 was that liquid solution was used weekly
before full save. No idea if that was excessive, just the practice at that
location. I know the cleaning tapes have a usage limit.

John McKee

On Wed, Apr 2, 2014 at 8:22 AM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>wrote:

Heh. If one wanted to, one could expand this a bit and, in a loop, delay
however many days one wanted. Or wait until a specific day of the week.
Or . . . well, you get the idea.

Put it in a separate CL program and use it wherever.

On Wed, Apr 2, 2014 at 9:16 AM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

At one prior employer...

I added an couple extra DLYJOBs
Original:
QSYS/DLYJOB RSMTIME(&STIME)

Modified
QSYS/DLYJOB RSMTIME(&STIME)
QSYS/DLYJOB DLY(600)
QSYS/DLYJOB RSMTIME(&STIME)

This allowed me to start the program at 5pm Friday, yet have the save

kick

off at 2am Sunday.

So instead of the normal upto 24hr delay, my version gave a 24-48 hr

delay.

Charles

On Tue, Apr 1, 2014 at 5:00 PM, John McKee <jmmckee@xxxxxxxxxxxxxx>

wrote:

Traditionally (times change), backup was performed late Saturday night.
That could be changed. May have to be. One option being explored is
telling people that system will go down during daytime for backup.

Might

not like that. They want to hurry and finish accounts on it.

If unattended need to be run from the console, somebody could enter

command

during Friday and it would tke off on Saturday night. I forgot to ad

that

the inactive time would also need to be set to *NOMAX and restored
. People walk away from sessions and leave protected information
displayed. Bad for a hospital.

John McKee

On Tue, Apr 1, 2014 at 3:51 PM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

Why isn't the up to 24hr delay of GO SAVE good enough?

That automatically shuts down into restricted state.

Personally, I do a RTVCLSRC on QMNSRBND, that's where the option 21 -

Save

entire System is done.

I call it SAVESYSTEM, added some code to cleaning shut down our

system

jobs

and and built a command front end for it.

You'll want to also want to remove the parm and add
CHGVAR VAR(&OPTION) VALUE('QMNSAVE')

You end up with a program that display's the save entire system

screen,

and

you can specify the time to start.

Charles

On Tue, Apr 1, 2014 at 4:29 PM, John McKee <jmmckee@xxxxxxxxxxxxxx>

wrote:

Still riding system to oblivion. We >may< be losing our only

opportunity

for an attended backup every other week. I have been asked to

explore

alternatives.

No money.

I read in Infocenter that GO SAVE 21 has a capability to be set up

to

24

hours in the future. Not a scheduled job, just sits in DLYJOB.

The

thought occurred to me of writing a CL that would be submitted to
controlling subsystem (BCTL in our case) which would end to

restricted

state and perform backup. Just a little afraid of that. If

something

failed, with no workstation available, how could anybody know?

I retrieved the source for the GO SAVE 21 CLP, QMNSAVE. Two parms

are

passed, &DFT and &CANCEL DFT has a length of 118, but the defaults

data

area has a length of 200. I am assuming that is just a quirk, as

the

data

area is blank beyond 120 or so.

It looks like the CaNCEL parm is populated and sent back.

I am thinking that this retrieved source could be modified to have

no

parameters. Just do RTVDTAARA and run the commands. Add an

appropriate

DLYJOB at the top so it could be started from the console and it

would

wait

until the appropriate time. Would need to also end the online

system

before subsystems are ended. I have that code already.

Final piece is to get the media library to pull tapes as needed. I

presume

the changes to accomplish that are made through the front panel?

This

is

3590 E11.

Gets a bit more confusing: We have a single 3590. yet a WRKCFGSTS

*DEV

TAP* shows:

TAPMLB01 VARIED ON
TAPMLB02 VARIED OFF
TAP35 VARIED ON
TAP35OLD VARIED OFF

TAPMLB01 was created by auto config. It shows device type 3590

E11.

This

shows resource of TAP01 deallocated.

TAPMLB02 has *RSRCNAME for device type and model. No resources

listed.

Can't vary on TAPMLB02 after vary off of TAP35. I am not

surprised,

based

on no resoueces.

I do not know why there are two MLBs. My thought is both are

"incorrect".

Many years ago, there was a TAP01.

Ran WRKHDWRSC TYPE(*STG), TAPMLB01 is only tape library.

Was media library even set up correctly? It has never been used,

as

far

as

I know.

I can add config source if it will make any sense.

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

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

--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
--
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.