ACCOUNT number information incorrect

Products

• VM:Backup High-Speed Disaster Recovery Option (HiDRO)

Issue/Introduction

Does HiDRO switch its account during backup activities ?  

 

Environment

We have HIDRO running backups and are now looking into using the ACCOUNT data for users in z/VM.I noticed that HIDRO occasionally switches its account number. This can be seen in both CP MONITOR and CP ACCOUNT. When idle, HIDRO is using its assigned ACCOUNT as configured in the directory. USER HIDRO AUTOONLY 128M 256M BCG ACCOUNT BACKUP When it is running backups, it switches to account number "1". For instance in DISKACNT: HIDRO BACKUP 061317200002"""?"b"b"& """ HIDRO 1 061317200031NONE ADMSERV 0191" HIDRO 1 061317200031NONE AUDITOR 0191" Here we can see the ACCOUNT is written at 20:00:02 (CP ACNT ALL CLOSE). At 20:00:31 the DAILY backup is started. All records during the backup are now with ACCOUNT 1. After the backup ends,it is back to account BACKUP. The same is observed during a VMIMAGE backup. This behaviour has not been seen in any other user. Could it be that HiDRO switches it's account during backup activities ?

Resolution

The Account Records in question are Type-5 “LINK Journal” Account Records, as opposed to LOGON or other usage Account Type Records. 

Although it's not clearly stated in the format of the Type-5 Account Record (columns 9-16 = Account Number), the Account Number is that of the user that owns the minidisk that is being linked to, not the user that is doing the LINK.

The setting of the HiDRO default option ACCOUNT does change this. The ACCOUNT setting (ON or OFF) is referenced in the HiDRO MODULE (there is no flag set in the HiDRO code for this). This default is only stored in the HIDRO CONTROL file. 

When a job is submitted, SYSBSHELL sets up the job environment. Part of that processing reads the HIDRO CONTROL file. If the setting for ACCOUNT is set to ON, this causes SYBSHELL to call an external HiDRO supplied routine (SYBACT) that issues a Diagnose x'4C' with sub-function x'0000' to set Account Record generation to the "Requesting UserID" (the UserID that submitted the job). The intent here is that the submitter of the job will be "charged" for the resources used for that job.