¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Re: IOGEN on TK4- - Failed...


 

Mattis,

Looking at the IOGEN.JCL you submitted, there are no 2703 devices. Can you attach what you fed into STAGE1?

Joe

On Sat, Jul 25, 2020 at 11:59 AM Mattis Lind <mattislind@...> wrote:
Hello All IOGEN experts!

I want to change on of the 2703 devices in the TK4- config to act as a BSC3 device so I started to try to do an iogen on tk4- and failed completely.

The steps described in the TK4- is a bit sketchy at least with the amount of MVS knowledge I have.

Performing an IOGEN?

The following procedure isn¡¯t meant to be a cookbook style recipe; in depth MVS systems programming knowhow is required to follow it. Although the TK4- system is set up such that this procedure should work reliably, the author cannot guarantee this. For good reasons IOGENs and SYSGENs always were amongst the most hated tasks on IBM¡¯s vintage operating systems.?

?

1.Create a backup copy of the system (one never knows¡­).?

2.Deactivate RAKF: o Submit jobs RAKF.SAMPLIB(VSAMSRAC) and RAKF.SAMPLIB(VTOCSRAC) to clear the RACF indicators. Note: It is advisable to submit VTOCSRAC using TYPRUN=HOLD and logoff the TSO session before releasing the job. VTOCSRAC will have some issues with long dataset names under the TK4- HLQ. These can safely be ignored.?

3. Change SYS1.PARMLIB(RAKFINIT) from YES to NO.?

4. Re-IPL the system. The system is now ¡°disarmed¡±, i.e. while RAKF is still installed, it is no longer active and will grant each and every request. For more information see the RAKF User¡¯s Guide, which can be unzipped in PDF or MS-Word format from RAKF.SAMPLIB($DOC$ZIP).?

5.Edit job SYS1.SYSGEN.CNTL(IOGEN) to reflect the desired changes and submit it. Check for errors and rerun as needed!?

6. Run job SYS1.UMODCNTL(REST-ALL) and then all jobs from SYS1.UMOD.RESTORE.CNTL. ?

7. Shut down the system.?

8. IPL the starter system (if you don¡¯t have it, get it from the original TK3 CD).?

9. Submit job SYS1.STAGE1.IOGEN.OUTPUT from MVSRES. Check output for errors, there generally shouldn¡¯t be any condition codes higher than 4.?

10. Shutdown the starter system and perform an IPL CLPA of the TK4- system. Of course you now experience a vanilla system, particularly in terms of TSO session capabilities¡­ so, be warned and don¡¯t worry!?

11.Run job SYS1.SYSGEN.CNTL(IO-JCLIN) to bring SMP back into synch.?

12. Run job SYS1.UMODCNTL(APPL-ALL) to get all usermods back into the system. Carefully read and follow the warning message issued to the console upon submission of the job: You must ensure, that all apply jobs are run sequentially. If they don¡¯t, you¡¯re guaranteed to completely mess up your system.?

13. Shut down the system and perform an IPL CLPA.?

14.Reactivate RAKF: o Set the setracf parameter in jobs RAKF.SAMPLIB(VSAMSRAC) and RAKF.SAMPLIB(VTOCSRAC) to ON and submit them to switch the RACF indicators back on. Note: It is advisable to submit VTOCSRAC using TYPRUN=HOLD and logoff the TSO session before releasing the job. VTOCSRAC will have some issues with long dataset names under the TK4- HLQ. These can safely be ignored. o Change SYS1.PARMLIB(RAKFINIT) from NO to YES.?

15.? Re-IPL the system. The system is now ¡°armed¡±, i.e. RAKF will enforce all profiles defined in SYS1.SECURE.CNTL. For more information see the RAKF User¡¯s Guide, which can be unzipped in PDF or MS-Word format from RAKF.SAMPLIB($DOC$ZIP).?

16. Enjoy your new I/O configuration.


At 10 everything went south. Step 2 seems not to be necessary since these indicators are set to off already (?). Doing step 3 and then step 4 gave me a system that didn't ask me for password when logging in.

Then I did step 5. Just a tiny change and submitted it. All seemed well. There were a huge file generated in SYS1.STAGE1.IOGEN.OUTPUT. The file looked ok. Contained a number of jobs to be run later.


Now I did step 6 which worked fine as well. Actually later on when re-IPL this system to get the??
SYS1.STAGE1.IOGEN.OUTPUT out to be able to submit it (probably a very stupid way of doing things..) I found that there were things that didn't behave as they used to. But I assume this has to do with the fact that a number of user mods has been removed and maybe wasn't working exactly as it used to.

At step 7 it was starting to get tricky. I downloaded the TK3 CD. Extracted the START1 DASD and SPOOL0 DASD and moved them into my DASD catalog as well as the starter.conf file from the tk3 CD. After some trials the starter system booted up nicely. I then ran the SYS1.STAGE1.IOGEN.OUTPUT file which I had extracted out of the tk4- system directly on the card reader of ther starter system.

I am not sure that this went ok. But "All available functions complete" is a good sign is my experience.

$ telnet localhost 3270

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

Hercules version 3.13 built on Jul 18 2020 22:49:58

running on mattis-HP-EliteBook (Linux-4.4.0-186-generic.#216-Ubuntu SMP Wed Jul 1 05:34:05 UTC 2020 x86_64 MP=4)

Connected to device 0:001F

IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.70.VS2

HHCTE006A Enter input for console device 001F

r 0,clpa

?IEF165I // START JES2

?IEE351I SMF SYS1.MAN RECORDING NOT BEING USED

*00 $HASP426 SPECIFY OPTIONS - HASP-II, VERSION JES2 4.0

r 0,noreq

?IEE600I REPLY TO 00 IS;SUPPRESSED

?IEE041I THE SYSTEM LOG IS NOW ACTIVE

?$HASP160 PUNCH1 ? INACTIVE - CLASS=BK

?$HASP125 READER1? SKIPPING FOR JOB CARD

?$HASP150 SYSLOG ? ON PRINTER1

?$HASP150 INIT ON PRINTER1

?$HASP250 SYSLOG ? IS PURGED

?$HASP150 INIT ON PRINTER1

?$HASP250 INIT IS PURGED

?$HASP150 INIT ON PRINTER1

?$HASP250 INIT IS PURGED

?$HASP160 PRINTER1 INACTIVE - CLASS=AJ

?$HASP250 INIT IS PURGED

?$HASP100 INIT ON STCINRDR

?$HASP373 INIT STARTED

?$HASP100 INIT ON STCINRDR

?$HASP373 INIT STARTED

?$HASP100 INIT ON STCINRDR

?$HASP373 INIT STARTED

?$HASP309 INIT? 1 INACTIVE *** C=A

?$HASP309 INIT? 2 INACTIVE *** C=BA

?$HASP309 INIT? 3 INACTIVE *** C=CBA

?$HASP099 ALL AVAILABLE FUNCTIONS COMPLETE

$pi2-3

?$HASP000 OK

?$HASP395 INIT ENDED

?$HASP150 INIT ON PRINTER1

?$HASP160 PRINTER1 INACTIVE - CLASS=AJ

?$HASP099 ALL AVAILABLE FUNCTIONS COMPLETE

?$HASP250 INIT IS PURGED

?$HASP395 INIT ENDED

?$HASP150 INIT ON PRINTER1

?$HASP160 PRINTER1 INACTIVE - CLASS=AJ

?$HASP099 ALL AVAILABLE FUNCTIONS COMPLETE

?$HASP250 INIT IS PURGED

?$HASP100 IOG11 ON READER1 SYSTEM GENERATION

?$HASP100 IOG12 ON READER1 SYSTEM GENERATION

?$HASP100 IOG13 ON READER1 SYSTEM GENERATION

?$HASP100 IOG14 ON READER1 SYSTEM GENERATION

?$HASP100 IOG15 ON READER1 SYSTEM GENERATION

?$HASP101 IOG15 HELD

?$HASP099 ALL AVAILABLE FUNCTIONS COMPLETE


The last job was HELD. It makes sense since TYPRUN=HOLD was set on the last job in the jcl file. I have no idea what the reason for this is though?

Here is the file:

I thought that giving $A command to have the job released should work, but it didn't succeed. I then just removed the TYPERUN=HOLD on the last job. Re-ran the job and then it wasn't held any longer.


Now at step 10 I restarted the original TK4- system but now something had really became very strange. A lot of things refused to start and didn't work as it used to do so I assume I had corrupted the system.

You guys that have done this multiple times can probably easily spot what I had done wrong!

Thanks,

/Mattis



Join [email protected] to automatically receive all group messages.